Talk:AccessControl plug-in - Revision history

BerndS at 09:46, 29 August 2018

2018-08-29T09:46:46Z

â† Older revision		Revision as of 09:46, 29 August 2018
Line 33:		Line 33:
	"GenericRead + GenericExecute + GenericWrite + Delete"		"GenericRead + GenericExecute + GenericWrite + Delete"
	</highlight-nsis>		</highlight-nsis>

			== 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\

Anders: Updated to reflect changes in latest version

2016-01-01T19:46:58Z

Updated to reflect changes in latest version

â† Older revision		Revision as of 19:46, 1 January 2016
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.


	~~== 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 [http://pastebin.com/dqik1L2A easily be modified] to support a couple of the basic SID strings like AN,AU,BA,BU,SY and WD.

	~~[[User:Anders\|Anders]] 21:57, 23 March 2014 (UTC)~~

	== KEY_WOW64_64KEY inheritable ACE propagation ==		== KEY_WOW64_64KEY inheritable ACE propagation ==

Anders: Linked to a custom version of ConvertStringSidToSid with SID strings support I made

2014-03-23T21:57:42Z

Linked to a custom version of ConvertStringSidToSid with SID strings support I made

â† Older revision		Revision as of 21:57, 23 March 2014
Line 57:		Line 57:
	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 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.		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 [http://pastebin.com/dqik1L2A easily be modified] to support a couple of the basic SID strings like AN,AU,BA,BU,SY and WD.

	[[User:Anders\|Anders]] 17:39, 23 March 2014 (UTC)		[[User:Anders\|Anders]] 21:57, 23 March 2014 (UTC)

	== KEY_WOW64_64KEY inheritable ACE propagation ==		== KEY_WOW64_64KEY inheritable ACE propagation ==

Anders: Typo

2014-03-23T17:40:50Z

Typo

â† Older revision		Revision as of 17:40, 23 March 2014
Line 57:		Line 57:
	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 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 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.		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.

	[[User:Anders\|Anders]] 17:39, 23 March 2014 (UTC)		[[User:Anders\|Anders]] 17:39, 23 March 2014 (UTC)

Anders: Added some issue/bug notes

2014-03-23T17:39:03Z

Added some issue/bug notes

@@ Line 25: / Line 25: @@
 == 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 ==
@@ Line 48: / Line 49: @@
 *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.

Anders: IsUserTheAdministrator has been removed

2014-03-23T16:50:22Z

IsUserTheAdministrator has been removed

â† Older revision		Revision as of 16:50, 23 March 2014
Line 33:		Line 33:
	</highlight-nsis>		</highlight-nsis>

	~~==The IsUserTheAdministrator problem==~~
	~~I'm able to trick this export to both return "no" when the admin group is enabled in the process token, and "yes" when the admin group is a deny SID.~~

	~~You are better off using the UserInfo plugin if you need to check if the current user has admin access rights since it already has support for deny SID's and "dynamic group membership".~~

	~~If you just need the SID or info about a user other than the current user, this export is fine.~~

	== Questions and Answers ==		== Questions and Answers ==

213.5.11.38: Explained why SDDL SID strings do not work.

2013-03-05T15:03:11Z

Explained why SDDL SID strings do not work.

â† Older revision		Revision as of 15:03, 5 March 2013
Line 53:		Line 53:
	::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.

87.102.96.222: /* Questions and Answers */ Added a question.

2013-03-05T12:00:05Z

Questions and Answers: Added a question.

â† Older revision		Revision as of 12:00, 5 March 2013
Line 52:		Line 52:
	*Q: I want to give permmisions to file and not to folder as you show on your examples. How can I do it??		*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.		::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?

217.5.177.162: /* Questions and Answers */

2012-12-13T12:52:17Z

Questions and Answers

â† Older revision		Revision as of 12:52, 13 December 2012
Line 50:		Line 50:
	*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)?		*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)		::A: (no answer yet)
	*Q: I ~~wnt~~ to give permmisions to file and not to folder as you show on your examples. How can I do it??		*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.

84.94.226.250: /* Questions and Answers */

2012-10-17T14:50:10Z

Questions and Answers

â† Older revision		Revision as of 14:50, 17 October 2012
Line 50:		Line 50:
	*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)?		*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)		::A: (no answer yet)
			*Q: I wnt to give permmisions to file and not to folder as you show on your examples. How can I do it??