|SmithJoe||User Rights (to be admin or not to be admin, that is the question)|
|14th Jun, 2011 19:53|
User Since: 14th Jun, 2011
System Score: N/A
i've got some simple questions that are not clear to me.
Does Secunia need admin rights to run? The website states that it does, but i read some infos on the net that said that secunia now doesn't need admin rights any more (that info looked like a press release from secunia that was published on other websites).
If it does not need admin rights to run, does it need admin rights to install patches via auto-update ??
Thanks for your support
|ddmarshall||RE: User Rights (to be admin or not to be admin, that is the question)|
|14th Jun, 2011 21:21|
User Since: 8th Nov 2008
System Score: 98%
|PSI starts two services: the Secunia PSI Agent and the Secunia Update Agent. These run in the System account. This means that PSI can run and update while you are running as a Standard User. This was not possible with earlier versions of PSI.
The Tray icon application runs in the current users account. If you are a Standard User you can see pop-ups from the icon. If you double-click the icon, you will get a UAC prompt and you will have to enter an administrator password to load the user interface. You will then be running in the administrator account you chose. This applies to Vista and Windows 7, of course.
|libove||RE: User Rights (to be admin or not to be admin, that is the question)|
|17th Jun, 2011 09:28|
User Since: 12th Feb 2008
System Score: N/A
|Forgive me for the hijack; this calls out an open bug/feature-request for PSI.
ddmarshall is exactly correct, of course, and what I want to re-emphasize (I've posted about this before) is that the exact model which PSI uses for *which* administrator equivalent account PSI runs as can create a conflict for users of systems with more than one administrator equivalent account in existence (in particular, Domain member systems will have this problem, but I imagine it could happen on standalone systems with multiple administrators).
I always run as a non-administrator user. So, I always use UAC elevation when I need to perform adminsitrative tasks, including launching the PSI user interface by clicking on the PSI tray icon.
The PSI service process appears to run as .. well, I'm not sure, actually; but it seems to run as some other user ID than any ID as which I interact with the system, and it stores its current scan status and results as that other ID. When I click on the PSI task tray icon and UAC elevate, I see a different set of status/ scan results, and have to manually re-scan to get current information.
The access control model for PSI needs to be enhanced a little bit, so that the PSI background service runs as SYSTEM and always stores all status/scan information the same way, and then intermediates with the PSI user interface to access that one consistent set of information.
Ideally, PSI would be configurable to know a specific set of users who would be granted access through the PSI user interface *even without administrative/UAC elevation*, so that non-administrator people could approve software updates executed by PSI at the user's convenience, without ever having to give the user admin rights. (Not all software can be auto-updated by PSI, and not auto-updateable software by PSI should be allowed to auto-update without the non-admin user of the PC giving approval).
Minimally, PSI at least should access any administrator/ elevated user and show them the one consistent set of status/scan information.