LockPermissions [problem]

[jacquesh]

Hello IS Community ;

I've repackaged an very old application what has needded full write right on it's own directory (c:\APPNAME\DIR1) ; i found informations like [%USERDOMAIN] but all informations found like [Everyone] don't works. :eek:

How can i give full right for AllUser or DomainUser to APPDIR(c::\APPNAME) ??

Thanks.

[looeee]

not [Everyone] but Everyone

[jacquesh]

I've same error.

I found another information using BuiltIn/Users but my Domain Server is in French ; I must using BUILTIN/Utilisateurs ... that works fine !!

Only one problem persist :: I can't set permission recursively ?? do you have a tips for that ??

:cool:

[looeee]

You could take advantage of a bug (??) in windows installer

http://support.installshield.com/kb/view.asp?pcode=ALL&articleid=Q107639

[TsungH]

If you have not, please take a look at this thread. There are numerous discussions on setting permissions. You may want to do a search on LockPermissions in the forums and at Support.

[Christopher_Pai]

Do not walk, run to the nearest exit. Avoid LockPermissions at all costs. Even Robmen would agree with me:

http://sourceforge.net/mailarchive/message.php?msg_id=11205989

"There is (WIX) work planned to enhance the SecureObj code to
be able to set permissions on directories and registry keys since the
LockPermissions table is so close to useless."

[patrikb]

I agree on the fact that the lock permissions table is next to useless when setting permissions to the registry as the perms aren't set recursively (well actually, sometimes they are and at other times they aren't).

For files and folders it works as expected (at least for me). One of the most important things about setting permissions the "msi-way" is the fact that permissions are set to files and components. To set permissions to a directory, you have to set the ACL's to the component that copies the first file to that directory. If it's an empty dir the only way I've managed to set perms is to create a new component that set the ACL's.
The "BuiltIn\[GroupName]" account groups are language specific. What other alternatives are there to set permissions not bound to a specific domain?

Maybe the best way of setting ACL's is through a custom action, and if you want to roll back permissions, the only way of doing it, is through a roll-back custom action...

[Christopher_Pai]

I suspect LockPermissions was castrated by Microsoft on purpose. The idea was probably to force developers to code based on operating system default permissions and discourage setup developers from changing those permissions to accomodate poorly written programs.

[patrikb]

Ok? You don't like lockPermissions, do you? :rolleyes:

Still, I state that it works quite good on files and directories. The "msi-way" may not be the best, but it works 😛

[Christopher_Pai]

I've been bitten too many times to suggest that it "works".

One of our vendors ( a large well known company ) provided a release that used an MSI install. They had to create an emergency release and ask that all of the original media be destroyed!

The reason? LockPermissions.

You see, when MSI applies ACLs using LockPermissions it doesn't merge with existing inherited permissions, it breaks propogation and creates a whole new set of ACL's. This is SOOO Windows NT 4.0 not Windows 2000.

Anyways they somehow authorered in permissions at the HKEY_CLASSES_ROOT level and managed to create a boatload of problems.

The title of the problem report was "can't install other applications after installing xxxxxxxx"

And this was a product that was certified Windows Logo certified product...