ACLs support in managed code

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">We are debating features for the
"urn:schemas-microsoft-com:office:smarttags" /> style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">BCL style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">… one that has come up a lot in the
past is ACLs support in System.IO. 
Do you think it is worthwhile to expose ACLs off FileStream? style="mso-spacerun: yes">  What scenarios do you need those
for? />

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Thanks!

Comments (9)

  1. Cory Smith says:

    Why would ACL functionality be part of the FileStream? Wouldn’t they be better situated in the IO.Directory and IO.File space? I am thinking of ACL meaning Access Control List, correct? I just don’t really understand how FileStream and ACL are related… what are you thoughts regarding this?

  2. Anonymous says:

    I agree with Cory. Actually, I’d go a step further and not tie ACL support to the System.IO module, since far more things deal with ACLs and SDs than just files, and you’d like those to be supported too.

    How about System.Security.DiscretionaryAccess or System.Security.AccessControl or something like that?

  3. brad says:

    Yea, sorry, i don’t know if FileStream is the right place… my main question is should we expose it at all, and if so what would you do with it?

  4. Please, please, pretty please make it along the lines of the classes found in atlsecurity.h, instead of being a direct wrapper of the NT 3.1-esque API.

    I, for one, would like to use it to secure named pipes, for which I by the way wouldn’t mind if support as a remoting channel was added to the BCL itself (and not just as a separate download). I guess the Rotor guys would have to implement them as domain sockets.

  5. Definately expose it as a concept.. People developing application need access to ACL’s when developing administative type tasks eg build and deployment type applications. Personally I think if you can access/ do an acion in the in the operating system why shouldn’t you be able to do it in code.

    Similar to the person above I think that ACL’s are an abstract idea.. You should be able to apply an ACL to any type of object. For example You might want to add security Permissions to an object in the Active Directory. Give a user permission to a SQL server stored procedure or a file on the file system. Therefore, I feel that there needs to be some sort of base class/interface that allows you to deal with security permission on these objects in a similar way..

  6. Why not just hoist System.Messaging.AccessControlEntry and System.Messaging.AccessControlList out of System.Messaging and expose ways to use them against other resource types that can be ACL-secured? These types really don’t seem to be System.Messaging centric – there are similar access control issues shared between queues, pipes, files, and other Win{32|64} objects.

  7. Wayne Allen says:

    Definately expose the ACL functionality. Please, do not tie them directly to the System.IO classes. So many permission based operations could be simplified this way.

  8. Duncan Godwin says:

    I would really like to see every major aspect of Windows API’s as part of the BCL – I can dream 🙂 Here are some some scenarios I’ve used ACL’s. 1) Setting up users and setting the permissions on their home directory as part of a domain. 2) ISP type setup, I’ve used the Windows 2000 Inherited ACL’s to define a structure with multiple organisational units each of which can have sub-sites and provide permissions for delegated access to sites to additional users for managing single sites. This provided the permissions for a user logging in under ftp, and even if they could guess other paths to sites and organisational units they would be denied. If possible I would like to see these defined or at least accessible off both File and Directory objects even if they are defined in System.Security and reused for other ACL users such as AD.

  9. And I quote, "…the runtime security is in addition to, not an alternative to, operating system security." Written by your very own Rudi Martin in the book ".NET Framework Security" (pg. 448) The question is moot really. Ask yourself this question. Does anything in the BCL provide functionality that replaces the ACL functionality? If not then it means that you cannot easily use .NET to write an application that fully utilizes the Windows platform functionality. FWIW, I agree with previous comments that the entire Win32 API surface area should have/should be wrapped "out of the box". Do you have any idea how many folks have created their own wrappers around Win32 API’s and related structures? What’s worse is that many of them are incorrect. I know one thing is that I’m actually much more likely to use ACL’s if they have a nice managed wrapper around them. Those baby’s are hideous to use from C/C++.

Skip to main content