So for all y'all haters of the LockPermissions table out there out there the Windows Installer Team Blog says it's the best practice, just include local admins and whatever else you need.

Also I was able to engineer a server app with moderately complex business requirements based on permissions, which used the LockPermissions table but was liable to errors using CA methods.

Mr. Ian! What do you think? Looking forward to comments and feedback.
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Community Chosen Answer

1
Hello,

I once had an interview and when I mentioned I used xcacls and similiar tools like that in custom actions to set permissions he said they only allowed use of the Lock Permissions Table and that is the only allowed method at his project.

I thought it was odd then that at all the places I worked it was a standard practice to use that in a custom action to set permissions over the Lock Permssions Table.

I sent an email direct to Acresso (Installshield Admin studio) asking if the Lock Permissions Table should always be used over my custom action methods.

This was the reply I got from them:

********************************
Regardless of the tool you're using, Windows Installer has a table called 'LockPermissions', which we expose in the Files and Folders and Registry views of the InstallShield Project file (*.ism).

However, there are some significant limitations associated with this such that Microsoft is rewriting this feature in a future release of Windows Installer. So, there may be some cases where you'll need to end up relying upon the custom action approach that you've used in the past.

Some scenarios that I'm aware of:

--Not natively localizing user groups based on well-known SIDs
--Appending to an existing ACL (it replaces the existing one)
--The following knowedgebase entry:

Q107639: PRB: Registry Permissions Propagate Upwards to Parent Keys
http://kb.acresso.com/selfservice/viewContent.do?externalID=Q107639

*****************************
Answered 03/20/2009 by: LB3
Senior Yellow Belt

Please log in to comment
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
Where possible I use the lockpermissions table, its native and quicker than using a CA..

Only use subinacl when I need to set permissons on shared resources..
Answered 03/20/2009 by: Tone
Second Degree Blue Belt

Please log in to comment
1
Practice shmratcice. Who cares? LockPermissions is the Spawn of The Devil and they know it. They've been told what hymn sheet to sing from, simple as. If they REALLY thought that, why haven't they put in the work to

- add the normal/default Windows groups/users in to the table automatically;
- abandon the ludicrous number-to-permission level nonsense

Oh...wait...I know. It's because we're only up to v4.5. They haven't had time.
Answered 03/21/2009 by: VBScab
Red Belt

Please log in to comment
0
I agree, the numbering thing is really annoying, and administrators:f should be default if it's going to replace and not edit permissions (also a questionable decision). Also I notice that discussion is from a lock down perspective (make it more secure) whereas from a packaging perspective we usually loosen perms (users:c) to allow "dumb" apps to work.

Still, if the Windows installer team says it's a best practice it must be so. Argument from authority and all that....:-)
Answered 03/23/2009 by: aogilmor
Ninth Degree Black Belt

Please log in to comment
0
ORIGINAL: aogilmor
Still, if the Windows installer team says it's a best practice it must be so.  Argument from authority and all that....:-)



LOL. Im sure All developers follow those standards.
But anyway, back to the real world......
Answered 03/23/2009 by: reds4eva
Second Degree Blue Belt

Please log in to comment
0
lately I've been using secedit to create the security.inf file and calling that from a custom action/wisescript.
Answered 03/23/2009 by: ditch_nz
Purple Belt

Please log in to comment
0
MS's Best Practices also state that software should be installed to %ProgramFiles%\NameOfVendor\ProductName\VersionNbr. Thus we get 'C:\Program Files\Microsoft Office'... Oy! Shouldn't that be 'C:\Program Files\Microsoft\Office'? And what's with 'C:\Program Files\Internet Explorer' and 'C:\Program Files\NetMeeting'?

Give me a break...
Answered 03/24/2009 by: VBScab
Red Belt

Please log in to comment
0
Maybe "best practice" will work when the MsiLockPermissionsEx table is in place :D

Enhanced Permissions Setting with Windows Installer 5.0
http://blogs.msdn.com/windows_installer_team/archive/2009/03/05/enhanced-permissions-setting-with-windows-installer-5-0.aspx
Answered 03/24/2009 by: AngelD
Red Belt

Please log in to comment
0
thanks, I'll check that out!
Answered 03/24/2009 by: aogilmor
Ninth Degree Black Belt

Please log in to comment
0
I'd be curious as to the details of how yiou did that, I tried once and even though the inf file worked fine from the command line the msi always got errors. I gave up and used another method. (and yes I read the previous posts here, and used the search!)
Answered 03/24/2009 by: aogilmor
Ninth Degree Black Belt

Please log in to comment
1
ORIGINAL: ditch_nz

lately I've been using secedit to create the security.inf file and calling that from a custom action/wisescript.



Ive had occasion to use secedit but usually only when I need to change both file/folder and registry permissions. Otherwise whatever gets the job done, lock permissions table, xcalcs, subinacl etc.

Owen ,this works.
http://itninja.com/blog/view/command-line-access-to-wmi-in-xp3
Answered 03/24/2009 by: reds4eva
Second Degree Blue Belt

Please log in to comment
0
thanks maybe I'll try that next time. the advantage to secedit as I see it is that you can do more than file/reg perms at one go - for example 'log on as a service etc.
Answered 03/24/2009 by: aogilmor
Ninth Degree Black Belt

Please log in to comment
0
ORIGINAL: AngelD

Maybe "best practice" will work when the MsiLockPermissionsEx table is in place :D

Enhanced Permissions Setting with Windows Installer 5.0
http://blogs.msdn.com/windows_installer_team/archive/2009/03/05/enhanced-permissions-setting-with-windows-installer-5-0.aspx



And you packages are only going to Windows 7
Answered 04/10/2009 by: Tone
Second Degree Blue Belt

Please log in to comment
0
ORIGINAL: Tone

ORIGINAL: AngelD

Maybe "best practice" will work when the MsiLockPermissionsEx table is in place :D

Enhanced Permissions Setting with Windows Installer 5.0
http://blogs.msdn.com/windows_installer_team/archive/2009/03/05/enhanced-permissions-setting-with-windows-installer-5-0.aspx



And you packages are only going to Windows 7


I wouldn't say that, my comment was regarding when to treat Microsoft's "best recommendation" of using the LockPermissions table.
Answered 04/12/2009 by: AngelD
Red Belt

Please log in to comment
0
My point although not very clear and aimed at no post in particular- was its a good idea that overdue but cant really be implemented unless they pull their fingers out and release it a downlevel installer.

Was to lazy to just type MsiLockPermissionsEx [:)]
Answered 04/13/2009 by: Tone
Second Degree Blue Belt

Please log in to comment
0
For anyone looking to know the joys and pains of using MsiLockPermissionsEx, here is a tutorial, some best practices and a helper script. The helper script extracts SDDL from existing system resources - so you just use Regedit and Windows Explorer to set permissions and the helper script extracts them for you.

You can check it out here: http://csi-windows.com/toolkit/csigetsddlfromobject
Answered 11/17/2010 by: 007sQ
Yellow Belt

Please log in to comment
0
about time you found your way here Darwin :-)
Answered 11/17/2010 by: jmcfadyen
Fifth Degree Black Belt

Please log in to comment
Answer this question or Comment on this question for clarity