tlalit
29th March 2006 16:15 UTC

dll permissions
I have a problem:
when reboot is needed after admin reinstalls the plugin to a restricted user (update), NSIS leaves registry keys (NSIS.RegTool etc.) to know what DLL's need to be registered and replaced after the reboot. my problem is that after the reboot is done and NSIS finished with it's stuff the restricted user does not have permissions on the replaced dll's and the result is that the plugin does not load.
I'm using the InstallLib macro and because the dll is occupied - reboot is needed, but the restricted user does not have the permissions while the plugin is working just fine to the admin that installed through the RunAs command.

tlalit
30th March 2006 15:36 UTC

can anybody help me???
Is it not clear enough?

Afrow UK
30th March 2006 17:41 UTC

Searched forum for 'permissions' and came across this:
http://forums.winamp.com/showthread....ht=permissions
I have no experience in this area so I don't know if this is what you are after.

-Stu

kichik
31st March 2006 13:06 UTC

When installing DLLs that require an update after reboot, the user must be an administrator. This is required for both the registration which uses the HKLM\...\RunOnce key and for the replacement itself using MoveFileEx, which eventually needs to write to HKLM\...\PendingFileRenameOperations.

To check if a user is part of the administrators group, you can use the UserInfo plug-in, which is packaged with NSIS.

tlalit
2nd April 2006 08:05 UTC

Yes, I know that the user have to be admin - and this is not the problem... even if admin runs the installation (with the RunAs) and after the Required Reboot the admin is the one that logging on - the restricted user still has problem of permissions on the replaces dll's.

kichik
2nd April 2006 18:30 UTC

What permission exactly is the restricted user missing? Can you provide a simple example so I can understand what you're after?

Do you mean the restricted user doesn't have access to read the DLL files? The file permissions should be inherited from the folder where the DLL is installed. Normally, that'd be either the system directory or the program directory. Both should be readable even to a restricted user. Is the DLL installed to such a directory and is still unreadable?

tlalit
3rd April 2006 14:13 UTC

The restricted user has no permission at all, (right clicking the dll show no security tab). so it means that also the restricted user doesn't have access to read the DLL files. the premissions on the folder are good and only the replaces dll's after reboot (the one needed updates) have this problem.
FYI, dll's that were not replaced in the same folder - looks OK, so, I'm guessing its not a folder permission problem. and again, the admin user that made the update can work with these dll's with no problems.

kichik
3rd April 2006 20:10 UTC

If it only happens in this specific folder, it is probably a problem with the folder permissions. In the Advanced dialog of the security tab for that DLL and its folder, is the "Inherit from parent..." check box marked?

Does it happen with every DLL you install? Do I understand correctly and it happens only with one specific folder? Does it still happen if it's only replaced after reboot and not registered? What exactly are the permissions for the DLL when this happens? Does it happen just on one computer or can you reproduce it on others? As I can't reproduce this with my examples, can you attach a minimal example?

tlalit
4th April 2006 14:05 UTC

The scenario is to run an installer for restricted user with the RunAs command but when InstallLib is trying to replaced dll's and registered them, they have to be in use - so they will be replaced and registered only after the reboot. and after the reboot be sure to login as the admin - so that the replacemant and registration can be done (this is another problem...)

It look like the problem is that the "Inherit from parent..." checkbox unchecked for all dll's that were replaced after the reboot with the admin, the question is why is it happenning and how can this be fix?

kichik
4th April 2006 16:08 UTC

It works fine for me with or without runas. Please answer the other quetsions as well, I need more details.

Comperio
4th April 2006 17:36 UTC

While you are gathering the answers to Kichik's questions, here's something else to consider:

If you are using Windows XP Pro, it defaults to having "Simple File Sharing" enabled. With this feature, user's don't see the "Security" tab on a file/folder's properties screen.

To disable simple file sharing, go into explorer, click tools->folder options, click the View tab and scroll down to the very bottom. (Windows XP Home does not allow you disable simple file sharing.)

tlalit
5th April 2006 17:39 UTC

OK I'll try to answer your questions:
it doesn't happen in a specific folder - it happend to dll's (and not folders) that were replaced after reboot by RunAs admin user to a restricted user(I tried not register - and it still happen)
The "Inherit from parent..." check box is checked.
It still happen if it's only replaced after reboot and not registered.
The Permissions for the DLL's are good (read/write etc.) only for admins, but the "Users" group is not include - and I'm guessing this is the problem - when adding this group - it looks like the problem is solved...
Was this information helpfull?

kichik
5th April 2006 20:05 UTC

Is the inherit check box checked on the folder as well? Does this happen on every computer? Can you attach an example? The easiest way for me to solve it is to be able to reproduce it.

BTW, as a workaround, you can use AccessControl to grant access to the replaced DLL. Use it on the temporary file created in Library.nsh just before the Rename /REBOOTOK line.

tlalit
6th April 2006 10:35 UTC

I think the problem is that the "inherit from parent..." check box for the replaced dll's is checked when no reboot is needed (after admin installed for restricted with RunAs), but when dll's needed to ne replaced after reboot the "inherit from parent..." (after admin installed for restricted with RunAs) check box is unchecked...

kichik
7th April 2006 10:31 UTC

How does the check box change for the folder depending on the reboot?

Can't you attach an example script? Is it confidential?

Try creating a simple script which only installs one DLL which will be replaced on reboot and nothing else. Keep as minimal as possible with only one section that installs the DLL, no MUI and no callback functions.

tlalit
10th April 2006 16:57 UTC

OK, I made 2 installers, the dfference between the instrallers is the dll version, how can I submit these 2 installers?

kichik
14th April 2006 10:51 UTC

Zip them, click on Post a Reply and use the attachment box on the bottom. If they're too big, you'll have to upload them somewhere like stashbox.

tlalit
23rd April 2006 17:39 UTC

I sent two the 2 installers:

tlalit
23rd April 2006 18:03 UTC

I sent two the 2 installers:
1. first install example1 with admin user (close outlook before doing that), now look at file permission of the dll installed under "program files/Test1"
2.log in to computer as restricted user, open outlook and run example2 with the RunAs command with admin user. you'll ask to reboot the computer ...
3. reboot the computer and login as the admin user you used with the RunAs command.
now look at the file permission again - you'll see the difference.

kichik
28th April 2006 11:46 UTC

Your temporary directory for extraction is $TEMP. That's not good. You should use $INSTDIR as the temporary directory for extraction (the last parameter). $TEMP can be on a different drive than $INSTDIR, in which case moving the file after reboot will not work. It can also have different permissions as it probably is in your case.

tlalit
30th April 2006 10:08 UTC

well, it looks like you were right :-)
thanks... problem solved!!!
have a great independence day...