How do I programmatically check EFFECTIVE delete (modify) or write permissions in .NET?

Question

Sorry in advance for the long question. What I'm really interested in is a way to programmatically check if the executing windows identity has adequate windows privileges to write to a directory (or file) in an ASP.NET web services application. But I'll settle for retrieving effective delete (modify) privileges for a user for a given directory or file. The problem is that I would like to be able to do this without either writing temporary files OR necessarily performing the IO action and handling the exception.

Yes, there is a question on this already ( see http://stackoverflow.com/questions/137031/how-can-i-programmatically-determine-if-i-have-write-privileges-using-c-in-net) Normally I would agree with the accepted answer that the best method is to just try the IO action and handle any exceptions -- System.IO methods do throw System.UnauthorizedAccessException to indicate failure as a result of privilege denial. But in the case of of UPLOADING files, I'd really like to check the privileges BEFORE wasting the time and resources of uploading the data since it is only AFTER upload that we can attempt to write the file or folder in question. I pity any users uploading a 2GB file over http only to be told after the upload completes that they don't have permissions to upload the file to the destination.

The usual approach to testing write access if you don't want to perform the actual write is to write a temporary file. The other question has an answer pointing this out. This is what our code currently does. BUT windows security allows write access without delete privileges. Users with ONLY write access but no delete end up leaving all sorts of undeleted .tmp files. And no, we don't want to use a Domain admin account to reset the ACL on the tmp files and then delete them. The approach I've been taking is to check if the user has write privileges using System.IO.Directory.GetAccessControl(..) or System.IO.File.GetAccessControl(..) and dealing with the various access rules and ACE returns... but with this I still have issues dealing with EFFECTIVE privileges -- i.e. in most cases I also have to look up the user's membership in any of the groups listed in the ACE that do have permissions on the object. There has to be an easier way.... doesn't there?

Answer 1

Well kudos for going the extra mile on user experience AND trying to maintain clean program structure. Maybe if you're uploading only you could try to create an empty 'placeholder' file with the same name as the final 2GB file will have, then just overwrite it. Not perfect since you could still end up with an empty file, but pretty easy and at least a little bit more elegant that some of the alternatives.

Answer 2

@Paul, I really like your answers, and I think that in normal web applications where there is a known and relatively small set of potential upload target directories, you have the proper solution: 1 - If the application might have users that do NOT have Append Data privieleges, all upload directories should have a known test file that Append operations are tested against to check prior to uploading.
2 - If there is no worry about Append Data privileges, then the application can just write out an empty version of the file and append to it on upload. I'm accepting your answer to make sure you get credit for this.

Unfortunately, in my application we do NOT have a finite or known set of upload target directories -- any share or folder in the network may be accessible. What we are going to implement is buffering of the upload data in relatively small chunks and open the target file in Append mode BUT hold a FileStream OPEN for the duration of the upload (yes there are concerns for handling FileStreams that are this long lived) This gives a fast exception (happens as soon as the first chunk is written to the FileStream) if there are no write privileges w/o being dependent on Append Data privileges. But I would NOT recommend this design to anyone -- if you can get away with it try one of @Paul's suggested solutions. And if you don't have to worry about early messaging of lack of write privileges on upload, just handle the exceptions and don't worry about it.

Answer 3

You could also have permanent file, say 'access_test.txt', which you try to overwrite with a datestamp or something to first to test the current access.