Vista - How to change 'Group' permissions on existing folder?

I have a similar issue to Bob Eaton's previous post in that I have an app
that stores data in [CommonAppData]/Company/Application. I need to give the
local/users group 'modify' rights to this folder and have the modify right
propagate to child files and folders.

By the way, 'local/Users' also inherits special permissions on this folder
which allow users to create files/objects and append data. So the first time
a file is saved to this folder by a LUA user it works just fine. However,
they can't edit the content of the files or overwrite them later.

I can set the permissions as part of an installation custom action that runs
with elevated priviledges but I'm having trouble setting the actual
permissions.

The code that I'm trying to use is:

Sub Set_Folder_Permissions()
'Retrieve the Directory Security descriptor for the directory
Dim DirectorySecurity As DirectorySecurity =
Directory.GetAccessControl(Settings.CommonAppDataPath,
AccessControlSections.Access)

'Create a new Access Rule
Dim accessrule As New FileSystemAccessRule("users",
FileSystemRights.Modify, InheritanceFlags.ObjectInherit,
PropagationFlags.None, AccessControlType.Allow)

'Add the access rule to the Directory Security Descriptor
DirectorySecurity.AddAccessRule(accessrule)

'Persist the Directory Security Descriptor to the directory
Directory.SetAccessControl(Settings.CommonAppDataPath,
DirectorySecurity)
End Sub

However, this isn't changing the 'Users' group access rights on the folder.
No exceptions are generated either.

Of course, the Users group is already inheriting Read & Execute, Read, List
folder Contents from the parent folder. I can manually add 'Modify' (which
also turns on 'Write') at this level and it's inherited by lower level
objects correctly. But my code isn't adding the modify right and that's my
main problem.

Second, I'm concerned about hard coding 'Users' as the account. I thought
that 'Users' was locale specific and I should use a well known sid.

My questions are: Am I doing something wrong with the code above? How to I
add the Modify right for the 'Users' group on a folder?

Second, do I need to worry about hard coding 'Users' rather than using a
well known SID? If so, how do I go about using the well known SID?

Thanks,

Jason Eskew

"Jason" <Jason@discussions.microsoft.com> wrote in message
news:EB17EB39-00EB-4480-9BA3-1947EC1F936E@microsoft.com...
>I have a similar issue to Bob Eaton's previous post in that I have an app
> that stores data in [CommonAppData]/Company/Application. I need to give
> the
> local/users group 'modify' rights to this folder and have the modify right
> propagate to child files and folders.
>
> By the way, 'local/Users' also inherits special permissions on this folder
> which allow users to create files/objects and append data. So the first
> time
> a file is saved to this folder by a LUA user it works just fine. However,
> they can't edit the content of the files or overwrite them later.
>
> I can set the permissions as part of an installation custom action that
> runs
> with elevated priviledges but I'm having trouble setting the actual
> permissions.
>
> The code that I'm trying to use is:
>
> Sub Set_Folder_Permissions()
> 'Retrieve the Directory Security descriptor for the directory
> Dim DirectorySecurity As DirectorySecurity =
> Directory.GetAccessControl(Settings.CommonAppDataPath,
> AccessControlSections.Access)
>
> 'Create a new Access Rule
> Dim accessrule As New FileSystemAccessRule("users",
> FileSystemRights.Modify, InheritanceFlags.ObjectInherit,
> PropagationFlags.None, AccessControlType.Allow)
>
> 'Add the access rule to the Directory Security Descriptor
> DirectorySecurity.AddAccessRule(accessrule)
>
> 'Persist the Directory Security Descriptor to the directory
> Directory.SetAccessControl(Settings.CommonAppDataPath,
> DirectorySecurity)
> End Sub
>
> However, this isn't changing the 'Users' group access rights on the
> folder.
> No exceptions are generated either.
>
> Of course, the Users group is already inheriting Read & Execute, Read,
> List
> folder Contents from the parent folder. I can manually add 'Modify'
> (which
> also turns on 'Write') at this level and it's inherited by lower level
> objects correctly. But my code isn't adding the modify right and that's
> my
> main problem.
>
> Second, I'm concerned about hard coding 'Users' as the account. I thought
> that 'Users' was locale specific and I should use a well known sid.
>
> My questions are: Am I doing something wrong with the code above? How to
> I
> add the Modify right for the 'Users' group on a folder?
>
> Second, do I need to worry about hard coding 'Users' rather than using a
> well known SID? If so, how do I go about using the well known SID?
>
> Thanks,
>
> Jason Eskew

microsoft.public.platformsdk.msi might be better for this question since
it's really MSI custom action related and there's lots of experience over
there.

1. Make sure your custom action is running as a deferred and
non-impersonated custom action otherwise you won't have the necessary
privileges to edit the ACLs on your CommonAppData folder.

2. Whatever you do don't hard code "users" or any other well known name as a
string. I made that mistake once and spent a great deal of time with
patches for non-english locale systems. I'm not a .NET guy so probably
you'll get a much better response from someone else but FileSystemAccessRule
takes SecurityIdentifier as an argument and that looks like it can use
WellKnownSidType (e.g. BuiltinUsersSid). I hope that's enough to get you in
the right direction with help from msdn/web searches.

Sincerely,
Adrian Accinelli

>
> microsoft.public.platformsdk.msi might be better for this question since
> it's really MSI custom action related and there's lots of experience over
> there.
>
> 1. Make sure your custom action is running as a deferred and
> non-impersonated custom action otherwise you won't have the necessary
> privileges to edit the ACLs on your CommonAppData folder.
>
> 2. Whatever you do don't hard code "users" or any other well known name as a
> string. I made that mistake once and spent a great deal of time with
> patches for non-english locale systems. I'm not a .NET guy so probably
> you'll get a much better response from someone else but FileSystemAccessRule
> takes SecurityIdentifier as an argument and that looks like it can use
> WellKnownSidType (e.g. BuiltinUsersSid). I hope that's enough to get you in
> the right direction with help from msdn/web searches.
>
> Sincerely,
> Adrian Accinelli
>

Thanks for the reply. I'm not worried about the msi custom action. I have
other code that is running correctly in the custom action. This question is
specific to the accessrules issue.

On the subject of hard-coding users... That's what I thought. AccessRule
has an overloaded constructor that takes a SecurityIdentifier so I had tried
to use that. But I ran into a problem creating the SecurityIdentifier. The
constructor for it takes a well known sid enumeration and a
SecurityIdentifier. Gee, this means that I need the chicken before I can
create the egg? Specifically, I'm can't create the SecurityIdentifier
because I need to pass it a SecurityIdentifier. If anyone has a suggestion
as to where I could take a reference to an existing identifier, I'd be happy
to try it because supposedly it's ignored unless you are using one of several
specific well known sids (which doesn't include the localuser SID.)

Also, I did try creating a new NTaccount object and use the .translate
method to translate it to a SecurityIdentifier but I couldn't get the
SecurityIdentifier constructor to accept it.

"Jason" <Jason@discussions.microsoft.com> wrote in message
news8F064D6-E519-4276-8EB7-534152BE690F@microsoft.com...
>>
>> microsoft.public.platformsdk.msi might be better for this question since
>> it's really MSI custom action related and there's lots of experience over
>> there.
>>
>> 1. Make sure your custom action is running as a deferred and
>> non-impersonated custom action otherwise you won't have the necessary
>> privileges to edit the ACLs on your CommonAppData folder.
>>
>> 2. Whatever you do don't hard code "users" or any other well known name
>> as a
>> string. I made that mistake once and spent a great deal of time with
>> patches for non-english locale systems. I'm not a .NET guy so probably
>> you'll get a much better response from someone else but
>> FileSystemAccessRule
>> takes SecurityIdentifier as an argument and that looks like it can use
>> WellKnownSidType (e.g. BuiltinUsersSid). I hope that's enough to get you
>> in
>> the right direction with help from msdn/web searches.
>>
>> Sincerely,
>> Adrian Accinelli
>>
>
> Thanks for the reply. I'm not worried about the msi custom action. I
> have
> other code that is running correctly in the custom action. This question
> is
> specific to the accessrules issue.
Right - misread your first statement and thought the code was working
outside the custom action so jumped to the obvious issue wrt scheduling and
permissions and why I mentioned the other MSI related newsgroup.

>
> On the subject of hard-coding users... That's what I thought. AccessRule
> has an overloaded constructor that takes a SecurityIdentifier so I had
> tried
> to use that. But I ran into a problem creating the SecurityIdentifier.
> The
> constructor for it takes a well known sid enumeration and a
> SecurityIdentifier. Gee, this means that I need the chicken before I can
> create the egg? Specifically, I'm can't create the SecurityIdentifier
> because I need to pass it a SecurityIdentifier. If anyone has a
> suggestion
> as to where I could take a reference to an existing identifier, I'd be
> happy
> to try it because supposedly it's ignored unless you are using one of
> several
> specific well known sids (which doesn't include the localuser SID.)
>
> Also, I did try creating a new NTaccount object and use the .translate
> method to translate it to a SecurityIdentifier but I couldn't get the
> SecurityIdentifier constructor to accept it.

Again no expert (especially with VB) here but for built in "users" I think
it should be:

Dim sidType As WellKnownSidType
Dim domainSid As SecurityIdentifier
sidType = WellKnownSidType.BuiltinUsersSid
Dim sid As New SecurityIdentifier(sidType, domainSid)

Dim accessrule As New FileSystemAccessRule ( sid,
FileSystemRights.Modify, InheritanceFlags.ObjectInherit,
PropagationFlags.None, AccessControlType.Allow)

To set permissions explicitly for the user who launched the installation you
can retrieve the UserSID property from MSI. It can then be used to create
another SecurityIdentifier as above (assuming the code works

Sincerely,
Adrian Accinelli

> Dim sidType As WellKnownSidType
> Dim domainSid As SecurityIdentifier
> sidType = WellKnownSidType.BuiltinUsersSid
> Dim sid As New SecurityIdentifier(sidType, domainSid)

Thanks Adrian,

That little bit of code helped me change how I was thinking about the
problem enough to help me over the hump. The code below works and the
comments give additional insight into how I got it working and one of the
problems that I ran across.

Sub Set_Folder_Permissions()
'Retrieve the Directory Security descriptor for the directory
Dim dSecurity As DirectorySecurity =
Directory.GetAccessControl(Settings.CommonAppDataPath,
AccessControlSections.Access)

'Build a temp domainSID using the Null SID passed in as a SDDL
string. The constructor will accept the traditional notation or the SDDL
notation interchangeably.
Dim domainSid As New SecurityIdentifier("S-1-0-0")

'Create a security Identifier for the BuiltinUsers Group to be
passed to the new accessrule
Dim ident As New
SecurityIdentifier(WellKnownSidType.BuiltinUsersSid, domainSid)

'Create a new Access Rule.
'ContainerInherit AND ObjectInherit covers both target folder, child
folder and child object.
'However, when using both (combined with AND), the permissions
aren't applied. So just use
'objectinherit and the child objects (even created at a later time
in sub directories) inherit the permission correctly.
'Propagate.none means child and grandchild objects inherit.
Dim accessRule As New FileSystemAccessRule(ident,
FileSystemRights.Modify, InheritanceFlags.ObjectInherit,
PropagationFlags.None, AccessControlType.Allow)

'Add the access rule to the Directory Security Descriptor
dSecurity.AddAccessRule(accessRule)

'Persist the Directory Security Descriptor to the directory
Directory.SetAccessControl(Settings.CommonAppDataPath, dSecurity)
End Sub