Effective FileSystemRights for a WindowsIdentity???

11 Oct 2006 1:42 PM

Ed Sutton

Is there a FileSecurity method that can determine if the current
WindowsIdentity has "effective" file access permissions?

The challenge is the current identity may be "MYDOMAIN\JDOE", but I do
not know how to determine if a group this identity belongs, for example
"EVERYONE", permits write access for the identity?

The code below does not work for group permissions to which the
WindowsIdentity belongs to. It only works if the WindowsIdentity itself
has explicit file access permissions.

       // Do not use this code! Will return false *unless* the user has
explicit file access permissions
      private static bool IdentityHasAccces(FileInfo fileInfo,
                                            FileSystemRights
fileSystemRights)
      {
         System.Security.Principal.WindowsIdentity windowsIdentity =
System.Security.Principal.WindowsIdentity.GetCurrent();

         FileSecurity fileSecutiy = fileInfo.GetAccessControl();
         identityName = identityName.ToUpper();
         AuthorizationRuleCollection authorizationRuleCollection =
fileInfo.GetAccessControl().GetAccessRules(true, true,typeof(NTAccount));

         foreach (FileSystemAccessRule fileSystemAccessRule in
authorizationRuleCollection)
         {
            if ( true == (AccessControlType.Allow ==
fileSystemAccessRule.AccessControlType &&
                      fileSystemRights ==
(fileSystemAccessRule.FileSystemRights & fileSystemRights)))
            {
               // Test if this FileSystemAccessRule IdentityReference is
one of the Groups the current identity belongs to
               if (true ==
windowsIdentity.Groups.Contains(fileSystemAccessRule.IdentityReference) ||

windowsIdentity.User.Equals(fileSystemAccessRule.IdentityReference))
               {
                  return true;
               }
            }
         }
         return false;
      }

11 Oct 2006 3:24 PM

Joe Kaplan

You are much better off doing a p/invoke to the Win32 AccessCheck API rather
than trying to interpret the DACL yourself. It is very easy to make a
mistake.

The other sure fire way is to try the operation and catch the exception.

Joe K.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--

Show quoteHide quote

"Ed Sutton" <deleteThisedsutto***@hotmail.com> wrote in message
news:eubtXsT7GHA.3620@TK2MSFTNGP04.phx.gbl...
> Is there a FileSecurity method that can determine if the current
> WindowsIdentity has "effective" file access permissions?
>
> The challenge is the current identity may be "MYDOMAIN\JDOE", but I do not
> know how to determine if a group this identity belongs, for example
> "EVERYONE", permits write access for the identity?
>
>
> The code below does not work for group permissions to which the
> WindowsIdentity belongs to. It only works if the WindowsIdentity itself
> has explicit file access permissions.
>
>
>       // Do not use this code! Will return false *unless* the user has
> explicit file access permissions
>      private static bool IdentityHasAccces(FileInfo fileInfo,
>                                            FileSystemRights
> fileSystemRights)
>      {
>         System.Security.Principal.WindowsIdentity windowsIdentity =
> System.Security.Principal.WindowsIdentity.GetCurrent();
>
>         FileSecurity fileSecutiy = fileInfo.GetAccessControl();
>         identityName = identityName.ToUpper();
>         AuthorizationRuleCollection authorizationRuleCollection =
> fileInfo.GetAccessControl().GetAccessRules(true, true,typeof(NTAccount));
>
>         foreach (FileSystemAccessRule fileSystemAccessRule in
> authorizationRuleCollection)
>         {
>            if ( true == (AccessControlType.Allow ==
> fileSystemAccessRule.AccessControlType &&
>                      fileSystemRights ==
> (fileSystemAccessRule.FileSystemRights & fileSystemRights)))
>            {
>               // Test if this FileSystemAccessRule IdentityReference is
> one of the Groups the current identity belongs to
>               if (true ==
> windowsIdentity.Groups.Contains(fileSystemAccessRule.IdentityReference) ||
>
> windowsIdentity.User.Equals(fileSystemAccessRule.IdentityReference))
>               {
>                  return true;
>               }
>            }
>         }
>         return false;
>      }

13 Oct 2006 7:14 PM

Ed Sutton

Thank you Joe,

I will investigate the Win32 AccessCheck API.

Thanks again,

-Ed

Show quoteHide quote

"Joe Kaplan" <joseph.e.kap***@removethis.accenture.com> wrote in message
news:uxHsplU7GHA.1188@TK2MSFTNGP05.phx.gbl...
> You are much better off doing a p/invoke to the Win32 AccessCheck API
> rather than trying to interpret the DACL yourself. It is very easy to
> make a mistake.
>
> The other sure fire way is to try the operation and catch the exception.
>
> Joe K.

16 Oct 2006 1:44 AM

Alun Jones [MS-MVP - Windows Security]

"Joe Kaplan" <joseph.e.kap***@removethis.accenture.com> wrote in message
news:uxHsplU7GHA.1188@TK2MSFTNGP05.phx.gbl...
> You are much better off doing a p/invoke to the Win32 AccessCheck API
> rather than trying to interpret the DACL yourself. It is very easy to
> make a mistake.
>
> The other sure fire way is to try the operation and catch the exception.

I have to agree with Joe on this last step.

If you are trying to see if you have write access to decide whether to write
to the file or not, then just write to the file, and catch the exception (or
in other traditional languages, check the return value).

Asking "do I have permission to do XYZ" then doing XYZ leads to the obvious
race condition of the permission changing between the ask and the do, so you
have to add the code to catch the exception anyway - and then the ask
becomes a superfluous piece of code. Might as well not put it in in the
first place.

Alun.
~~~~

--
Texas Imperial Software | Web: http://www.wftpd.com/
23921 57th Ave SE | Blog: http://msmvps.com/alunj/
Woodinville WA 98072-8661 | WFTPD, WFTPD Pro are Windows FTP servers.
Fax/Voice +1(425)807-1787 | Try our NEW client software, WFTPD Explorer.