none
Change folder permission. RRS feed

  • Question

  • I would like to change the permission of the folder c:\program files\mySoftware\Data to FullAccess to the build-in group "Users".  I found the following article talking about FileIOPermission class and try to use it.  However, why the FileIOPermission class don't have parameter to specify the targeting user or group?

    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemsecuritypermissionsfileiopermissionclasstopic.asp


    I tried the following code but fail to change the permission for group Users

    string strDataPath=@"c:\Program Files\mySoftware\Data";
    FileIOPermission fileIOPerm1 = new System.Security.Permissions.FileIOPermission(PermissionState.Unrestricted);
    fileIOPerm1.SetPathList(FileIOPermissionAccess.AllAccess, strDataPath);

    Thanks
    Tuesday, October 18, 2005 4:18 PM

Answers

  • You are confusing code access security (CAS) with NTFS security.  I believe you want to give the Users group full access to the folder in NTFS correct?  With CAS you can't give a user any rights greater than they already have so if Users don't have write access to your directory (which they wouldn't in this case) you can't use CAS to give it to them.  Instead you need to move down to the security rights API of Windows.

    Prior to .NET 2.0 the security API is not exposed directly in .NET so you'll need to move into unmanaged code.  Not pretty to say the least.  In 2.0 you can call Directory.GetAccessControl(path) to get the security associated with a directory.  You can then make your changes and use Directory.SetAccessControl to set the new settings.  Of course unless the user has the rights it'll fail.

    Here is some pseudocode

    DirectorySecurity dirSec = Directory.GetAccessControl(path);
    dirSec.AddAccessRule(new FileSystemAccessRule("machine\Users", FileSystemRights.FullControl, AccessControlType.Allow));
    Directory.SetAccessControl(path, dirSec);

    I haven't verified but I believe this works for groups as well as users.  Note that you'll need to do some additional work because if the account already has a Denied ACL on the directory then it will take precedence.  Therefore you should first enumerate through the ACLs looking for a Denied ACL for the account and remove it prior to adding the new one.

    Michael Taylor - 10/18/05
    Wednesday, October 19, 2005 2:11 AM
    Moderator

All replies

  • You are confusing code access security (CAS) with NTFS security.  I believe you want to give the Users group full access to the folder in NTFS correct?  With CAS you can't give a user any rights greater than they already have so if Users don't have write access to your directory (which they wouldn't in this case) you can't use CAS to give it to them.  Instead you need to move down to the security rights API of Windows.

    Prior to .NET 2.0 the security API is not exposed directly in .NET so you'll need to move into unmanaged code.  Not pretty to say the least.  In 2.0 you can call Directory.GetAccessControl(path) to get the security associated with a directory.  You can then make your changes and use Directory.SetAccessControl to set the new settings.  Of course unless the user has the rights it'll fail.

    Here is some pseudocode

    DirectorySecurity dirSec = Directory.GetAccessControl(path);
    dirSec.AddAccessRule(new FileSystemAccessRule("machine\Users", FileSystemRights.FullControl, AccessControlType.Allow));
    Directory.SetAccessControl(path, dirSec);

    I haven't verified but I believe this works for groups as well as users.  Note that you'll need to do some additional work because if the account already has a Denied ACL on the directory then it will take precedence.  Therefore you should first enumerate through the ACLs looking for a Denied ACL for the account and remove it prior to adding the new one.

    Michael Taylor - 10/18/05
    Wednesday, October 19, 2005 2:11 AM
    Moderator
  • Do you means CAS does not target users or groups?  Is the rights applied by CAS work on all users provided that the rights are lower than that of the users'? 

    Thank you so much for explaining in details.
    Wednesday, October 19, 2005 9:48 AM
  • CAS is designed to explicitly (or even implicitly) specify the access rights that a piece of code either needs, would like to have, or doesn't need.  It can't be used to give a user any rights greater than they already have but it can limit them even further.  CAS is a .NET thing and therefore, for the most part, doesn't work with users and groups.  Instead it applies to the code being executed.  For example if you specify that your code requires full control access to C:\Program Files\MyApp then the code (or assembly) that contains this attribute will fail at runtime if the current user (possibly with other CAS-applied rules) doesn't have full control access to the directory.  It doesn't give the user full control.  It is also not influenced by user rights or group memberships.  By default apps run with full trust meaning they can do anything the user running the app can do.  As CAS is applied more of these rights are "taken away".  Conversely a partially trusted app has little rights but through CAS can be given "additional" rights for short periods of time, limited by the actual user's rights.  In .NET security is checked against the security policy in effective on the assembly, app domain, etc. and then against the OS so when you call File.Open, for example, the security policies defined by the assembly and CAS are checked first.  If they succeed then the underlying OpenFile API is called which will do its own security checking (this time against the actual user).

    CAS is used a lot when sandboxing code to prevent someone from misusing code.  For example many assemblies that do no work with the file system will use CAS to explicitly say that all access to the file system is denied within the assembly.  This prevents someone from using the assembly to access the file system anyway.  As a concrete example assume that your app supports addins.  Your addin assembly would probably set up some CAS attributes to limit the addin from accessing any file system objects outside your application directory.  You might also prevent registry access completely.  This means that if an addin using your assembly attempts to access the registry it will fail.  This prevents someone from creating an addin that, for example, searches the user's drive for music files.  Web apps use CAS a lot too.

    For more info on CAS you should refer to MSDN and the various articles online.  CAS is a complex topic and even now everyone is still understanding how and when to use it.  I don't completely understand it all myself.

    Michael Taylor - 10/19/05
    Wednesday, October 19, 2005 11:57 AM
    Moderator