Talk:AccessControl plug-in

Usage Example

  AccessControl::GrantOnFile \
    "$INSTDIR\database" "(BU)" "GenericRead + GenericExecute + GenericWrite + Delete"

You can't use it that way because your stack may be modified after that call. Because you don't know about causing an error (the error flag isn't set although an error occured) you have to check the stack:

  Push $0 ; save 
 
  Push "Marker" 
  AccessControl::GrantOnFile \
    "$INSTDIR\database" "(BU)" "GenericRead + GenericExecute + GenericWrite + Delete"
  Pop $0 ; get "Marker" or error msg
  StrCmp $0 "Marker" Continue
  MessageBox MB_OK|MB_ICONSTOP "Error setting access control for $INSTDIR\database: $0"
  Pop $0 ; pop "Marker"
 
Continue:
  Pop $0 ; restore

Solution to the problem with (BU) on Windows 7

Use the SID "(S-1-5-32-545)" instead of "(BU)" for Windows 7 - "(BU)" doesn't work. This may also help for non-English installations. This issue was fixed in v1.0.8.0?

Set the append/modify flag for ACLs

If you want to set the append/modify flag (in German: Aendern) for files/directories, set the accesscontrol flag to:

 "GenericRead + GenericExecute + GenericWrite + Delete"

NSIS v3

To use the plugin with NSIS you need to copy the Unicode dll (Unicode\Plugins\AccessControl.dll) to ${NSISDIR}\Plugins\x86-unicode\ and the ANSI dll (Plugins\AccessControl.dll) to ${NSISDIR}\Plugins\x86-ansi\

Questions and Answers

• Q: How can I upload the zip file containing the AccessControl port to NSIS Unicode?

A: See Uploading files.

• Q: I've downloaded the plugin but It only contains a dll file, not a nsh. The plug in usage manual details that the dll must go into the plugin directory, and the nsh into the include directory. What do I do now?

A: To install this plugin, extract the content of the ZIP archive into your NSIS folder and you are done. The plugin extends NSIS. This means that you do not have to load any NSH file or something. Simply use it like the example(s) show you. In simpler words: it works "out of the box". If you are still unable to write something like the above line:

 "$INSTDIR\database" "(BU)" "GenericRead + GenericExecute + GenericWrite + Delete"

you likely are inserting the line in the wrong place in the .nsi file (try moving it inside one of your "Section" entries)

• Q: I want to do someting like : </INHERIT> </REPLACE> which will delete existing ACL and force propagation from upper level. How can I delete existing ACL and replace with specified (SET)?

A: (no answer yet)

• Q: I want to give permmisions to file and not to folder as you show on your examples. How can I do it??

A: Setting permissions on a file works identically to the folder examples. Just specify the path to your file path (as on the destination system) instead a folder path.

• Q: With version 1.0.7.0 of the plug-in, specifying "(BU)" to grant registry permissions to all authenticated users (as per the examples) doesn't seem to work anymore. Has it been deprecated?

A: Actually, it was broken in 1.0.6.0 when NT4/ME compatibility was introduced in ANSI build. SDDL SID strings (BU, AU etc.) should still work in Unicode build. To work around this issue, use numeric SID constants, e.g. (S-1-5-11) for the Authenticated Users pseudo-group or (S-1-5-32-545) for the builtin Users group. There is a link on the plugin page to a Microsoft article with a list of well known SIDs. Starting with v1.0.8.0 (BU) should work everywhere.

KEY_WOW64_64KEY inheritable ACE propagation

RegSetKeySecurity is used when operating on a KEY_WOW64_64KEY handle, otherwise SetNamedSecurityInfo is used. This is a problem because RegSetKeySecurity is a older low-level function. Using SetSecurityInfo would seem like a solution but it supposedly ignores the KEY_WOW64_64KEY flag when opening a key internally so this is not a easy problem to fix...

Anders 17:39, 23 March 2014 (UTC)