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.

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"

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.

Windows version inconsistency

The exact version requirements are unclear and the plugin should be changed to add support for Win95 and NT4. It does not help that the Unicode and Ansi versions differ in their implementation.

The Ansi version tries to be Win95 compatible by GetProcAddress'ing RegSetKeySecurity even though it should be exported on Win95. This is rather pointless since it goes on to call SetNamedSecurityInfo, SetEntriesInAcl, BuildExplicitAccessWithName etc directly and those are NT4+/Win98+.

The Unicode version is almost NT4 compatible, only ConvertSidToStringSidW and ConvertStringSidToSidW should be GetProcAddress'ed and used if available, otherwise it should fall back to the re-implementation that the Ansi version uses. This re-implementation can easily be modified to support a couple of the basic SID strings like AN,AU,BA,BU,SY and WD.

Anders 17:39, 23 March 2014 (UTC)

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)