ACL support in the BCL


Brian Dewey gives a nice post on why you should care about ACLs… As you may know we plan to add ACL support to the BCL in Whidbey.. check out Kit’s PDC presentation for more info.  Here is some examples from that presenation… does it look like we are hitting the sweet-spot here?


Enable the ability to view and edit ACLs  on objects in the filesystem, from managed code


 


// how it might look for Directory…


DirectorySecurity ds = new DirectorySecurity();


 


ds.AddAccess (“MYDOMAIN\SomePerson”, AccessControlType.Deny,


      AclAccess.View | AclAccess.Change, FileAccess.ReadWrite );


 


Directory.SetAccessControl ( @“c:\temp”, ds );


 


 


 


Critical capability is setting the ACL at the point a file/directory is created


 


FileSecurity fs = new FileSecurity();


fs.AddAccess( new FileAccessTrustee( new NTAccount(“MYDOMAIN”, “SomeGroup”),       AccessControlType.Deny,       AclAccess.View | AclAccess.Change, FileAccess.Read |       FileAccess.Write));


 


using (FileStream file = new FileStream(“foo.txt”, FileMode.Create,    FileAccess.Write, FileShare.None, 4096,   false, fs ) ) {


            // write to the file…


 


 


 

Comments (10)

  1. This is a welcomed addition (that is an uderstatement). Anyone who has mucked around with raw ACLs just to set security on files or directories can tell this will save about 2 days of parsing the WinAPI docs figuring how to create an ACL from scratch and then apply it to a resource (file, directory, registry key, etc).

  2. I am assuming there is an EASY way to get at the ACL’s as well. Exception’al (haha) programming definitely incurs performance hits in the CLR and trying to actually gain access to a file, only to throw an exception telling me I don’t have access isn’t cool. Possibly some easy helper methods/properties like CanRead/CanWrite?

    I’m also hoping that access to these methods is protected by a new code access permission?

  3. Matthew Douglass says:

    Will there be a constructor version available for FileStream that doesn’t require setting all of those parameters but still provides ACL support? I know I’d certainly want to be able to leave things light buffer size at their default values while still getting access to easy ACL support.

  4. don’t you think it would be time NOT to allow the old DOMAINUsername form, and adopt the active directory friendly user@domain ?

  5. Nice! I’m definitely looking forward to this capability.

  6. Louis Parks says:

    If you don’t allow domainusername form, then you are cutting off support for everyone who doesn’t use AD. I don’t see the wisdom in that. What’s wrong with supporting both?

  7. SteveC says:

    Wow.

    Please name the crew working on this, I want to buy lunch(es) for them to backport it to Framework v1.1 so I can use it *now*.

  8. Excellent stuff.. wasn’t there a sample on gotdotnet a while ago?

  9. Rock and roll! I’ve been waiting for ACL support in the BCLs for a very long time! Awesome news.