0

I am currently writing an application that needs to examine the current user's permission for a file in the Windows file system given the file path. The application is written in C# .Net 4.0. I believe I am "in the right area", but am in need of help "driving it home". This question is in the right ballpark:Iterate through permissions on a file in the windows file system in C#, but is more concerned with multiple users - I am concerned with the current user.

Here is what I have so far:

FileSecurity fsObj = file.GetAccessControl(AccessControlSections.Access);
foreach (FileSystemAccessRule fsar in fsObj.GetAccessRules(true, true, typeof(System.Security.Principal.NTAccount)))
{
    FileSystemRights fsr = fsar.FileSystemRights;
    // examine current fsr for permissions...
}

My goal is to determine whether the user has write access to the file.

Community
  • 1
  • 1
Thomas
  • 6,291
  • 6
  • 40
  • 69
  • 1
    I don't believe you need to check the file itself for "write" permissions, but rather the folder... See this which explains how to do it... http://stackoverflow.com/questions/1410127/c-sharp-test-if-user-has-write-access-to-a-folder – Justin Russo Sep 23 '15 at 14:12
  • I think I'd go for catching the exception here - open the file for writing, if that succeeds, the user *currently* has permission to write to the file. Of course, a nanosecond later, a permissions change might be applied to the file and the user no longer has access, but that's *always* a possibility and not one your program will be able to work around. – Damien_The_Unbeliever Sep 23 '15 at 14:16
  • But catching exceptions order to determine access rights is very slow, especially if it need be done many times. – Marcus Sep 23 '15 at 14:17
  • @Marcus, you mean as opposed 'examinging'/'checking' each instance of a forloop over a FileSystemAccessRule Collection? – Brett Caswell Sep 23 '15 at 14:22
  • Yes, indeed. Most people don´t realize how expensive a try/catch is. And also, let´s regard what try/catch **should** be used for, catching possible errors, not to test variables for values. – Marcus Sep 23 '15 at 14:24
  • 1
    it's expensive it terms of memory, if you're suffering performance issues on it.. you're doing it wrong.. try catch goes outside of loops – Brett Caswell Sep 23 '15 at 14:25
  • 1
    I argue that using _catch_ do determine a value is terribly bad practice and has a significant performance impact. If you rarely enter the _catch_ clause _try_ will not impact performance. – Marcus Sep 23 '15 at 14:31
  • 1
    The problem is, there's no way to write the function "will this user be able to write to this file at some point in the future?". The actual only sane thing to do is to attempt to open the file for writing, at the point in time at which you intend to perform the writing. You can write as much additional code as you like but it's not going to solve that particular problem. And you will still have to write the code that catches the exception at the point of writing. – Damien_The_Unbeliever Sep 23 '15 at 14:35
  • @Marcus, the performance issue you're describing is when the exception actually occurs.. the catch operation itself doesn't impact performance any more than a Anonymous Funct retun would... with that said catching exceptions doesn't really relate to the question, as the OP is attempting to get file access information.. not perform an IO operation on a file, necessarily... though the logical conclusion is he's doing as a precursor to such an operation.. which will still need to handle the exceptions.. – Brett Caswell Sep 23 '15 at 14:40
  • @BrettCaswell Yes, that is true of course. My point is that if you use a try/catch clause when trying to write to a file, exceptions might be thrown for every file in a directory - severely impacting performance in comparison with a pre check for permissions. A try/catch would still be needed but checking for permissions first would reduce the number of times exceptions are thrown. – Marcus Sep 24 '15 at 07:22

1 Answers1

1

I believe it can be done as such (untested):

if ((FileSystemRights.Write & fsar.FileSystemRights) != FileSystemRights.Write) 
    return false;

return true;
Marcus
  • 8,230
  • 11
  • 61
  • 88
  • 2
    In complex situations, `FileSystemAccessRule`s can be `Deny` rather than `Allow`. You might have just confirmed that the user has been denied the right to write to the file but answered `true`. – Damien_The_Unbeliever Sep 23 '15 at 14:32
  • @Damien_The_Unbeliever I'll attempt to check for that. – Thomas Sep 23 '15 at 14:39