Yurik
18th February 2005 11:48 UTC

Can't obtain control under guest account
I've implemented admin rights checking in .onInit function with the UserInfo plugin. But I don't get control if I run the installation under very restricted Guest account. I've got a message "Access to the specified device, path or file is denied". So it seems that NSIS tries to access something implicitly (windows temp? appdata?). What minimum rights should user have to allow installer script to get control in .onInit to successfully perform rights thereafter?

kichik
18th February 2005 11:55 UTC

NSIS tries to find a place to place temporary files. But it never shows such an error message. I wonder which of the tests causes Windows to show such an annoying and uncalled for message. Are you running it in a simple Guest user or does it have more restrictions than the default?

BTW, it does start after the annoying error message, right?

Yurik
18th February 2005 12:05 UTC

kickik,

it seems that the matter is really caused with lack of rights to windows temp. On my desktop computer guest has rights by default, but as I've discovered, it has no rights to win temp. Having this, only the message mentioned appeared after running installation under guest. Nothing else, installation don't start after this message.
I've made some experiments and I've got control in .onInit after I grant guest with RW rights to win temp.

So it seems I need to specify in docs that for installed to work correctly, RW rights are required for temporary windows folder for an account under which one runs the installation.

BTW I think it could be of great conveniency if checking user rights is incorporated into NSIS itself. E.g. hooks like functions .adminInit, .guestInit, .powerUserInit, or maybe variable like $RIGHTS which is initialized internally and available in .onInit.

kichik
18th February 2005 12:52 UTC

I've created a guest user and removed its access to its own temporary directory. NSIS then used C:\Windows\Temp and was able to write there. It was not able to create the plug-ins directory because guests can't even delete their own files from that directory. That caused NSIS to show the "unable to initialize plug-ins..." message. I then tried to remove access from C:\Windows\Temp too. That caused NSIS to show the "unable to write to temporary directory message...", as should. I was not able to reproduce the Windows message and couldn't get NSIS to just exit without any message. Is there anything else you've done that I haven't?

The UserInfo plug-ins is there for checking user rights in the script. I don't see a need to implement it in the installer itself. Simple installers don't need it.

kichik
18th February 2005 13:41 UTC

OK, I have fixed plug-ins directory initialization for extremely restricted guest users with no directory listing access to the temporary directory.

I still can't reproduce your issue. Any more details that might help? Would you be able to provide me with remote access with a guest user having the same restrictions?

Yurik
18th February 2005 13:45 UTC

kichik,

it seems that the matter is not with NSIS, just simply foolish lack of rights to _run_ setup script (so it is Win message). Trying to reproduce (taking out the rights from guest right now), will write in some minutes.

Dealing rights in installer - simple installations also don't need PRINTHOOD and INTERNET_CACHE variables, but they are introduced. So maybe atleast $USER?

Yurik
18th February 2005 13:48 UTC

OK, I've got plugins message, so it's OK now. The only question that remains is can I (and how) customize this message (and other NSIS messages which issuing I can't control) in case I have a need?

kichik
18th February 2005 13:53 UTC

Even if it is just a Windows issue, I don't want Windows to spit off messages during an installation. It's possible to disable them, I just need to know what exactly triggers them. It'd also be for the best if NSIS gave its own message. There already is such a message, but it doesn't show on your guest user for some reason.

All of those weird directory variables came for free with the normal directory variables. Adding access control, which is usually unrequired, will bloat the basic exehead. I prefer keeping it as a plug-in.

The plug-ins message comes from build.cpp:3181 - add_plugins_dir_initializer(). You can not costumize it without changing the source code.

I'd still want to know how you've managed to get that Windows error message so I can get rid of it.

kichik
18th February 2005 14:25 UTC

From information provided by Yurik, it turns out the Windows error message was not NSIS related.