Talk:AccessControl plug-in: Difference between revisions
From NSIS Wiki
Jump to navigationJump to search
(Linked to a custom version of ConvertStringSidToSid with SID strings support I made) |
(Updated to reflect changes in latest version) |
||
| Line 24: | Line 24: | ||
== Solution to the problem with (BU) on Windows 7 == | == 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. | <strike>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.</strike> This issue was fixed in v1.0.8.0? | ||
| Line 48: | Line 48: | ||
::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. | ::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? | *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. | ::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 == | == KEY_WOW64_64KEY inheritable ACE propagation == | ||
Revision as of 19:46, 1 January 2016
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"
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)
