Prevent installer running if non-admin user

NEHOG
7th May 2008 20:20 UTC

Prevent installer running if non-admin user
I need to keep a non-admin user from running one of my installers (entering admin user credentials is not effective as the base programs requires the user be an admin user (not just giving credentials either!)

Is there a way to determine if the *user* is a non-admin user, so I could give an instructions message box to logon as an admin user to do the installation?

Anders
7th May 2008 20:37 UTC

Re: Prevent installer running if non-admin user

Originally posted by NEHOG
I need to keep a non-admin user from running one of my installers (entering admin user credentials is not effective as the base programs requires the user be an admin user (not just giving credentials either!)

This makes no sense, there is no way to detect if the user elevated with admin credentials, or was admin from the start (If your app needs admin rights to run, you should check for admin rights in your app(or fix you app ;) ))

The best you can do is:
add RequestExecutionLevel admin to your script, that takes care of Vista. for older systems, you can use the userinfo plugin in .onInit or .onGuiInit

AaronLS
7th May 2008 20:54 UTC

I think this might be what you want if you just want to know if the current user's account type is Administrator:
http://nsis.sourceforge.net/IsUserAdmin

If you concerned with the whole Vista issue where an admin can run a program either with User security or Admin, then I don't think IsUserAdmin is what you want.

NEHOG
8th May 2008 01:53 UTC

Re: Re: Prevent installer running if non-admin user

Originally posted by Anders
This makes no sense, there is no way to detect if the user elevated with admin credentials, or was admin from the start (If your app needs admin rights to run, you should check for admin rights in your app(or fix you app ;) ))

The best you can do is:
add RequestExecutionLevel admin to your script, that takes care of Vista. for older systems, you can use the userinfo plugin in .onInit or .onGuiInit

The reason is simple. The installed program does things that only an admin user can do. However, because of the (incredible) way that MSFT did Vista, it cannot be an admin level program! (If it is admin level, then Vista will not automatically run the program on startup... UAC strikes again).

And, we run our program at the end of setup, which is why I can't allow a non-admin user to even run the setup at all. (It doesn't help that setup is a two part program, with the second half written in VB.)

NEHOG
8th May 2008 01:56 UTC

Originally posted by AaronLS
I think this might be what you want if you just want to know if the current user's account type is Administrator:
http://nsis.sourceforge.net/IsUserAdmin

If you concerned with the whole Vista issue where an admin can run a program either with User security or Admin, then I don't think IsUserAdmin is what you want.

I looked at that URL and it did look interesting. I'll drop it into my installer tomorrow and see if it will work. I'll probably take the "RequestExecutionLevel admin" out of my setup program, though I suspect that won't matter (Vista will still try to require admin there...)

Anyway, thanks for the suggestion and link. I'll report back if it was successful.

Anders
8th May 2008 02:29 UTC

don't take out RequestExecutionLevel admin, yes Vista will elevate without it, but that is just detection that vista does and could go away at any time.

As far as startup goes, UAC is not the problem, your app is the one with the problem, just embrace the new age of non admin users and fix your app

NEHOG
9th May 2008 00:07 UTC

Originally posted by Anders
don't take out RequestExecutionLevel admin, yes Vista will elevate without it, but that is just detection that vista does and could go away at any time.

As far as startup goes, UAC is not the problem, your app is the one with the problem, just embrace the new age of non admin users and fix your app

Any program in the automatic startup locations (excluding RunOnce, which leaves a malware hole big enough to drive a Hummer through!) that is marked requireAdministrator will not run automatically on startup. This is not an application problem, but a Vista problem. The application cannot run for a non-administrator user, it is a system utility.

Life would be easier if I were writing a word processor or a calendar program, but unfortunately I'm not.

So, no my app is not the one with the problem, it is Vista and MSFT with the problem in that their attempt to fix a (perceived) problem simply broke more things than it fixed. An administrator *should* be able to have requireAdministrator marked programs in their startup, but MSFT missed the fine point.

Anders
9th May 2008 00:27 UTC

Originally posted by NEHOG
An administrator *should* be able to have requireAdministrator marked programs in their startup, but MSFT missed the fine point.

No, you missed the fine point, when UAC is on, a member of the administrator group is not actually admin, they are a standard user until they elevate with UAC. The shell (explorer) is not running with a admin token, so there is no way to start a elevated process...
Having 5 UAC dialogs on startup would not be fun would it?

There is a special admin account not affected by UAC, you could require your users to only use that account

---

RunOnce only runs for administrators IIRC, its never executed for normal users.

I assume you don't actually change system settings at startup, so you could just run as normal user until you need more access when the user changes a setting, then use a COM elevation object or something like that. Or you could go the other way and not care about security at all and install a service and let it do your dirty work like some dualboot app did when they claimed they bypassed UAC

AaronLS
9th May 2008 01:02 UTC

I personally feel Vista should only require elevated privileges to add something to run on startup as administrator, and from then on it allows it to automatically run at startup as administrator, because an administrator did allow that entry to be added.

This similar to how Linux works. There is a directory that you place scripts in that run at startup, which requires that you provide root credentials. Once it is in there however, it can run as root.

Regardless, I would just drop the discussion of which software is the "problem" and focus on a workaround such as one of those suggested by Anders. The fact is you can't fix Vista and recompile a new version for your users. You just have to accept it as it is. So that leaves it to the developer to shape the application to be jammed into Vista as best you can.

I hate Vista, but I try not to let it frustrate me because I know I have to support it, and the best I can do is learn as much about it as I can so that I'm empowered to overcome it's problems.

Try not to get to frustrated by Vista.

NEHOG
9th May 2008 18:19 UTC

Originally posted by AaronLS
I personally feel Vista should only require elevated privileges to add something to run on startup as administrator, and from then on it allows it to automatically run at startup as administrator, because an administrator did allow that entry to be added.

This similar to how Linux works. There is a directory that you place scripts in that run at startup, which requires that you provide root credentials. Once it is in there however, it can run as root.

Regardless, I would just drop the discussion of which software is the "problem" and focus on a workaround such as one of those suggested by Anders. The fact is you can't fix Vista and recompile a new version for your users. You just have to accept it as it is. So that leaves it to the developer to shape the application to be jammed into Vista as best you can.

I hate Vista, but I try not to let it frustrate me because I know I have to support it, and the best I can do is learn as much about it as I can so that I'm empowered to overcome it's problems.

Try not to get to frustrated by Vista.

Oh, I'm already frustrated by Vista! ;)

It is a very complex problem for us, our development budget and time don't allow for major rewrites (such as would be needed to split the application into separate service and UI components, and marketing is very specific in what they need (and I'm paid to deliver what they want...)

We're still testing, and working, and I'm sure I'll find solutions to our problems, but Vista is eating us up with its (IMHO poorly designed) security techniques.

What scares me is that MSFT will release a new version of Windows and base it on Vista!

vignesh447
12th May 2008 08:13 UTC

you can use the code below to check that:

;Does user have Admin privileges?
Push $R0
Call IsUserAdmin
Pop $R0
${If} $R0 == "false"
MessageBox MB_OK|MB_ICONEXCLAMATION "This installer must be run with Administrative Privileges"
Abort
${EndIf}

include the header file attached it works :)