Checking for directory and file write permissions in .NET

Question

In my .NET 2.0 application, I need to check if sufficient permissions exist to create and write to files to a directory. To this end, I have the following function that attempts to create a file and write a single byte to it, deleting itself afterwards to test that permissions do exist.

I figured the best way to check was to actually try and do it, catching any exceptions that occur. I'm not particularly happy about the general Exception catch though, so is there a better or perhaps a more accepted way of doing this?

private const string TEMP_FILE = "\\tempFile.tmp";

/// <summary>
/// Checks the ability to create and write to a file in the supplied directory.
/// </summary>
/// <param name="directory">String representing the directory path to check.</param>
/// <returns>True if successful; otherwise false.</returns>
private static bool CheckDirectoryAccess(string directory)
{
    bool success = false;
    string fullPath = directory + TEMP_FILE;

    if (Directory.Exists(directory))
    {
        try
        {
            using (FileStream fs = new FileStream(fullPath, FileMode.CreateNew, 
                                                            FileAccess.Write))
            {
                fs.WriteByte(0xff);
            }

            if (File.Exists(fullPath))
            {
                File.Delete(fullPath);
                success = true;
            }
        }
        catch (Exception)
        {
            success = false;
        }
    }

Solution 1

The answers by Richard and Jason are sort of in the right direction. However what you should be doing is computing the effective permissions for the user identity running your code. None of the examples above correctly account for group membership for example.

I'm pretty sure Keith Brown had some code to do this in his wiki version (offline at this time) of The .NET Developers Guide to Windows Security. This is also discussed in reasonable detail in his Programming Windows Security book.

Computing effective permissions is not for the faint hearted and your code to attempt creating a file and catching the security exception thrown is probably the path of least resistance.

Solution 2

Directory.GetAccessControl(path) does what you are asking for.

public static bool HasWritePermissionOnDir(string path)
{
    var writeAllow = false;
    var writeDeny = false;
    var accessControlList = Directory.GetAccessControl(path);
    if (accessControlList == null)
        return false;
    var accessRules = accessControlList.GetAccessRules(true, true, 
                                typeof(System.Security.Principal.SecurityIdentifier));
    if (accessRules ==null)
        return false;

    foreach (FileSystemAccessRule rule in accessRules)
    {
        if ((FileSystemRights.Write & rule.FileSystemRights) != FileSystemRights.Write) 
            continue;

        if (rule.AccessControlType == AccessControlType.Allow)
            writeAllow = true;
        else if (rule.AccessControlType == AccessControlType.Deny)
            writeDeny = true;
    }

    return writeAllow && !writeDeny;
}

(FileSystemRights.Write & rights) == FileSystemRights.Write is using something called "Flags" btw which if you don't know what it is you should really read up on :)

Solution 3

Deny takes precedence over Allow. Local rules take precedence over inherited rules. I have seen many solutions (including some answers shown here), but none of them takes into account whether rules are inherited or not. Therefore I suggest the following approach that considers rule inheritance (neatly wrapped into a class):

public class CurrentUserSecurity
{
    WindowsIdentity _currentUser;
    WindowsPrincipal _currentPrincipal;

    public CurrentUserSecurity()
    {
        _currentUser = WindowsIdentity.GetCurrent();
        _currentPrincipal = new WindowsPrincipal(_currentUser);
    }

    public bool HasAccess(DirectoryInfo directory, FileSystemRights right)
    {
        // Get the collection of authorization rules that apply to the directory.
        AuthorizationRuleCollection acl = directory.GetAccessControl()
            .GetAccessRules(true, true, typeof(SecurityIdentifier));
        return HasFileOrDirectoryAccess(right, acl);
    }

    public bool HasAccess(FileInfo file, FileSystemRights right)
    {
        // Get the collection of authorization rules that apply to the file.
        AuthorizationRuleCollection acl = file.GetAccessControl()
            .GetAccessRules(true, true, typeof(SecurityIdentifier));
        return HasFileOrDirectoryAccess(right, acl);
    }

    private bool HasFileOrDirectoryAccess(FileSystemRights right,
                                          AuthorizationRuleCollection acl)
    {
        bool allow = false;
        bool inheritedAllow = false;
        bool inheritedDeny = false;

        for (int i = 0; i < acl.Count; i++) {
            var currentRule = (FileSystemAccessRule)acl[i];
            // If the current rule applies to the current user.
            if (_currentUser.User.Equals(currentRule.IdentityReference) ||
                _currentPrincipal.IsInRole(
                                (SecurityIdentifier)currentRule.IdentityReference)) {

                if (currentRule.AccessControlType.Equals(AccessControlType.Deny)) {
                    if ((currentRule.FileSystemRights & right) == right) {
                        if (currentRule.IsInherited) {
                            inheritedDeny = true;
                        } else { // Non inherited "deny" takes overall precedence.
                            return false;
                        }
                    }
                } else if (currentRule.AccessControlType
                                                  .Equals(AccessControlType.Allow)) {
                    if ((currentRule.FileSystemRights & right) == right) {
                        if (currentRule.IsInherited) {
                            inheritedAllow = true;
                        } else {
                            allow = true;
                        }
                    }
                }
            }
        }

        if (allow) { // Non inherited "allow" takes precedence over inherited rules.
            return true;
        }
        return inheritedAllow && !inheritedDeny;
    }
}

However, I made the experience that this does not always work on remote computers as you will not always have the right to query the file access rights there. The solution in that case is to try; possibly even by just trying to create a temporary file, if you need to know the access right before working with the "real" files.

Solution 4

The accepted answer by Kev to this question doesn't actually give any code, it just points to other resources that I don't have access to. So here's my best attempt at the function. It actually checks that the permission it's looking at is a "Write" permission and that the current user belongs to the appropriate group.

It might not be complete with regard to network paths or whatever, but it's good enough for my purpose, checking local configuration files under "Program Files" for writability:

using System.Security.Principal;
using System.Security.AccessControl;

private static bool HasWritePermission(string FilePath)
{
    try
    {
        FileSystemSecurity security;
        if (File.Exists(FilePath))
        {
            security = File.GetAccessControl(FilePath);
        }
        else
        {
            security = Directory.GetAccessControl(Path.GetDirectoryName(FilePath));
        }
        var rules = security.GetAccessRules(true, true, typeof(NTAccount));

        var currentuser = new WindowsPrincipal(WindowsIdentity.GetCurrent());
        bool result = false;
        foreach (FileSystemAccessRule rule in rules)
        {
            if (0 == (rule.FileSystemRights &
                (FileSystemRights.WriteData | FileSystemRights.Write)))
            {
                continue;
            }

            if (rule.IdentityReference.Value.StartsWith("S-1-"))
            {
                var sid = new SecurityIdentifier(rule.IdentityReference.Value);
                if (!currentuser.IsInRole(sid))
                {
                    continue;
                }
            }
            else
            {
                if (!currentuser.IsInRole(rule.IdentityReference.Value))
                {
                    continue;
                }
            }

            if (rule.AccessControlType == AccessControlType.Deny)
                return false;
            if (rule.AccessControlType == AccessControlType.Allow)
                result = true;
        }
        return result;
    }
    catch
    {
        return false;
    }
}

Solution 5

IMO, you need to work with such directories as usual, but instead of checking permissions before use, provide the correct way to handle UnauthorizedAccessException and react accordingly. This method is easier and much less error prone.

View more solutions

Comments

[blowdart]

That will, of course, throw an exception if you can't actually get the ACL on the directory.

[Chris Chilvers]

It is also the only reliable method as otherwise someone could change the permission between checking and actually trying save (unlikely, but possible).

[Andy]

Thanks for this. So the only change I should do to my code is to catch a security exception instead of the general 'Exception'?

[Kev]

@Andy - yes, it's the path of least resistance unless you want to write the code to compute effective permissions.

[Ivan G.]

What does it check for? That directory has Write permissions, but for which user? :)

[Random]

This one does not work for groups but for literally added account names only in my case

[Bryce Wagner]

So is this something to do with "(S-1-5-21-397955417-626881126-188441444-512)" type format? Did converting the string to a SecurityIdentifier like that fix your issue? It's not clear from your comment whether it works now for you or not.

[Random]

When you put "rule.IdentityReference.Value" as parameter of currentuser.IsInRole() you use IsInRole(string) method which tries to match by regular "domain\user" value. So you are pushing SID string instead of user name string. However if you use my line in front of that you will get SecurityIdentifier object which match the user of given SID. That "string" argument overload is small trap for devs, once again it accepts account or group name in human redeable format not SID string representation.

[Bryce Wagner]

The problem is that "new SecurityIdentifier(SDDLFormat)" doesn't work with normal group names (you get an argment exception). So I added a check for whether it's in SDDL format.

[Donny V.]

It works if you just want to see if current user has write access.

[Vidar]

why does everything have to be so darned complicated!

[Triynko]

Things only appear complicated until you understand them. It's not that hard. You just get the Access Control List with Directory.GetAccessControl, then you get the AccessRules and look for Allow or Deny permissions on the rules your interested in (such as Read, Write, etc.). If you find NO rules, you have no access. If you find at least one Allow, then you have access, UNLESS you find even a single Deny. It's very basic security principles. See the other answer by Richard: stackoverflow.com/a/1281638/88409

[Triynko]

@aloneguid: The "GetAccessRules" methods returns an AuthorizationRuleCollection. The AthorizationRule class has an IdentityReference property, whose runtime type will actually be one of the two that derive from the IdenityReference type (either NTAccount or Security), which you can see is specified in the call to GetAccessRules. It is through the IdentityReference instance (or its derived types), that you can discover to which user the rule applies. It will be in the form of an SID or an NTAccount name.

[Triynko]

Also note that since the AccessControlType is for the rule as a whole, and the rule can specify multiple file system rights, there will be a separate rule for Allow permissions and Deny permissions for any single user (i.e. if both allow and deny permissions are set for a single user, then at least two rules will appear for that user. You can get the current user by calling WindowsIdentity.GetCurrent(), and add an additional check in the code above to see whether the rule applies to the current user.

[Triynko]

You may want to check the Groups member of the WindowsIdentity, because it will list the groups the user belongs to, and those groups may appear in the ACL as NTAccounts.

[Kev]

@Triynko - I suggest you read the article I quoted: groups.google.com/group/… - computing effective permissions is not as simple as it sounds. Be my guest and supply an answer to prove me wrong.

[Dmitry Dzygin]

@Bryce Wagner one of the "IF" statements should be removed because variable "sid" isn't in scope if (!currentuser.IsInRole(sid)) { continue; }

[Raven]

Try running this on your system disk on a windows 7 with a non admin application, it will return true, but when you try to write to the c:\ you will get a exception stating that you don't have access!

[Ilia Barahovsky]

This solution worked for me, but had one issue with network folder. The folder has access rule allowing write to BUILTIN\Administrators. And as I'm an administrator at my local station, the snippet mistakenly returned true.

[cjbarth]

You probably meant to say 'This method is easier and much less error prone.'

[Olivier Jacot-Descombes]

This does not take into account whether a rule is inherited or not. Local rules take precedence over inherited rules.

[Christian Casutt]

Directory.GetAccessControl(path) throws an {System.UnauthorizedAccessException)} - this should be caught in an exception handler i think ..

[Tolga Evcimen]

I think this answer is the best way to accomplish it, other answers use the same way to get the result too but since only this answer calculates the inherited rules and local rules it is the most accurate one I guess. Thanks&Congrats.

[beruic]

I agree. This returns some false trues for the current user.

[Kiquenet]

What is WellKnownSidType.WorldSid ?

[Jason Evans]

typeof returns the type of an object, in this case NTAccount. docs.microsoft.com/en-us/dotnet/csharp/language-reference/… The call to GetAccessRules() needs the type of the account when called. msdn.microsoft.com/en-us/library/…

[Kiquenet]

Why use NTAccount? always use NTAccount ?

[Jason Evans]

In this case, yes. NTAccount represents a user account on a Windows PC, which is why we need it in the above code.

[AussieALF]

Just a a random answer to your question @Kiquenet WorldSid is the "Everyone" buildin group.

[Richard Robertson]

This no longer works with .Net Core 3.1. GetAccessControl(path) no longer exists as a member of the Directory class. It is also not a member of the DirectoryInfo class either. I've just been beating my head for hours just trying to finda way to check if I can search a directory or not. Yay, Microsoft! Directory.Exists always returns true now permission or not.

[Breakwin]

Old thread. but how do I actually get the parameter FileSystemRights right to pass into the methods HasAccess

[Olivier Jacot-Descombes]

FileSystemRights is an enum having constants like ReadData, WriteData and so on. You have to pass in the enum constants you are interested in. They are flag values, so you can combine them like this: FileSystemRights.ReadData | FileSystemRights.ListDirectory.

[0xC0000022L]

This ignores the possibility of ACEs having an access mask with generic bits set, which I have seen in the real world.