tags:

views:

542

answers:

1

So I am trying to modify the permissions for the BUILTIN\Users group to at least have the Modify file system access right. Unfortunately, my attempts at using the below code produce unchanged ACL.

            SecurityIdentifier usersSecurityIdentifier = ntAccount.Translate(typeof(SecurityIdentifier)) as SecurityIdentifier;
            DirectorySecurity directorySecurity = Directory.GetAccessControl(source.FullName);
            FileSystemAccessRule accessRule 
                = new FileSystemAccessRule(@"BUILTIN\Users", FileSystemRights.FullControl, AccessControlType.Allow);

            directorySecurity.ModifyAccessRule(AccessControlModification.Add,
                accessRule,
                out modified);

            Console.WriteLine(modified);

Modified reports true in every case, but the perms are not updated when you look at them on the folder properties.

I have also tried to add an access rule for a SecurityIdentifier that did not not already have an ACL for the directory using similar code but just AddAccessRule instead of modify. Even though the new SecurityIdentifier showed up on the perms list for the directory they did not have the access I specified.

I am attempting to modify access for a proprietary directory in Environment.SpecialFolders.CommonApplicationData that an Administrator account is the owner of. I am also attepting to modify the ACL as an admin.

Does anyone have any idea what's wrong w/ the above code or have any resources that can lead me to the correct way of setting the ACL using native the native .NET classes?

A: 

I figured this out with the help of a friend who works at Microsoft. Actually the process I was using to set the ACL was accurate. I was interpreting the results incorrectly. Basically their is no problem setting the ACL on a directory this way as long as you're operating as an admin when you attempt to make the changes.

Accurate permissions for the folder were available for view (in Vista) by:

  1. Right click the folder in question and select properties
  2. Select the Security tab
  3. Click Advanced
  4. Click Edit
  5. Select the entity you wish to view permissions for and click Edit.

This is the part I was missing. CommonApplicationData path already has permissions set for the BUILTIN\Users entity. So after I run my code, I actually end up with two entities. One says Read & Execute and the other says Special Permissions. When I edit the entity with special permissions I actually see that the BUILTIN\Users do have access for the directory.

I was really looking for BUILTIN\Users to have access for the directory and all of it's child folders and objects. Here is a code snippet from what I ended up using. I was able to confirm my code worked both through a test harness and manually inspecting file and directory ACL lists.

DirectorySecurity directorySecurity = Directory.GetAccessControl(Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData));
FileSystemAccessRule accessRule
    = new FileSystemAccessRule(@"BUILTIN\Users", FileSystemRights.FullControl, 
        InheritanceFlags.ObjectInherit | InheritanceFlags.ContainerInherit, 
        PropagationFlags.None, 
        AccessControlType.Allow);

bool modified=false;
directorySecurity.ModifyAccessRule(AccessControlModification.Add,
    accessRule,
    out modified);

if (modified)
{
    source.Create(directorySecurity);
}
else
{
    source.Create();
}
Wil P
Thanks for posting this. What is the _source_ instance in the code snippet? Is this needed? Also, do I understand correctly that this code is to give Users full control to all of the CommonApplicationData path, including other apps' common data?
David Korn
It is a DirectoryInfo object. The reason for the code was to ensure that a user would have read / write / delete access to the CommonApplicationData path. What I found was that if an Administrator had created the path and was the owner of the directory then the User could not delete the path, so I basically wrote this code to make sure the all users had access to the directory and that they could delete it.
Wil P