Question Remove file permission then add back

kdn

New member
Joined
Jul 13, 2019
Messages
4
Programming Experience
1-3
Hi all,


This may be an odd request but here is what I am trying to do, I want to remove read permission for the user level account, then add that permission back when my application closes, I have it all working except I get thrown an exception when trying to add the permissions back, it seems I cut my own legs off so to speak when I remove the read attribute. Now the thing is, my console app is being run with administrator rights, and the administrator still has full rights to the file.

My code to remove the read attribute:

C#:
WindowsIdentity currentUser = WindowsIdentity.GetCurrent();

FileSecurity aclplus = new FileSecurity();

aclplus.AddAccessRule(new FileSystemAccessRule(currentUser.User, FileSystemRights.Read, AccessControlType.Deny));

File.SetAccessControl(passwordfile, aclplus);


then if I right click the file, I see the top acl is the logged in user (ie. Devicename\Bob) has a deny for read access, below that is Devicename\Administrators and it has full control allowed.

When I then try and add the read access back:


C#:
FileSecurity aclrm = new FileSecurity();

aclrm.RemoveAccessRule(new FileSystemAccessRule(currentUser.User, FileSystemRights.Read, AccessControlType.Deny));

File.SetAccessControl(passwordfile, aclrm);

I get an "access to path is denied" error. It would appear its trying to run the command as Bob with elevated rights rather than Administrator which understandably won't work, is there some way around this?
 
What happens if you add a rule to allow instead of removing one to deny?

The FileSystemAccessRule constructor will take a user name in a String too, but I would expect that you'd get prompted for a password at run time.
 
This is tangent to what your question is, but it sounds like it all you need to do is prevent access to the file while your program is running, just use file locks instead of playing with ACLs. It also has the fail safe of if your program crashes or power failure, the lock will be released instead of having to go back and twiddle the ACLs as a recovery step.
 
Why not use file stream lock instead? - FileStream.Lock(Int64, Int64) Method (System.IO) and to unlock - FileStream.Unlock(Int64, Int64) Method (System.IO)
Or File stream file share? - FileStream fileStr = new FileStream(Value, FileMode.Open, FileAccess.Read, FileShare.None);

I believe in your example if you remove such rights, you will likely/might need to add that permission back with elevated permissions or with the permissions of an admin. In order to do that, your application will need an app.manifest file to elevate your application to give it permissions to grant back the access. The trouble with this, is that your application will then be running with elevated permissions. Something you don't want unless your application need it all the time. I'd be incline to look at different options to what you have, personally.
 
When I then try and add the read access back:
I get an "access to path is denied" error.
This works fine for me, not sure why it doesn't for you. Tested with both inherited and explicit permissions, and with different owners of the file.
FileSecurity aclplus = new FileSecurity();
...
File.SetAccessControl(passwordfile, aclplus);
This is generally not a good idea, by doing this you start with an empty ruleset and when applied all existing explicit rules are removed, leaving only inherited ones. You should use File.GetAccessControl to get the existing FileSecurity and modify that. It does not affect my tests though, they were successfull either way.
What happens if you add a rule to allow instead of removing one to deny?
Both allow and deny can be set at the same time, including as explicit rules for a single user, deny will take precedence.
 
read permission
FileSystemRights.Read is actually more than just read permission:
Read131209Specifies the right to open and copy folders or files as read-only. This right includes the ReadData right, ReadExtendedAttributes right, ReadAttributes right, and ReadPermissions right.

This works fine for me, not sure why it doesn't for you. Tested with both inherited and explicit permissions, and with different owners of the file.
I wonder if our OP has accidentally wiped away any inherited ACEs that would have granted him access. Or if the OP is storing his file in a location which would by default not grant him rights.
 
thank you all for the replies. I have got it working now. I agree file lock is probably better so will look to use that instead, but as for the solution, it seems I had indeed lost all inherited rights to the file so I could not change the acl after the first attempt, what I did now is at the same time as removing read permissions I also add FileSystemRights.Modify permission.

It is an ugly solution and I will do it properly with your suggestions of either modifying GetAccessControl or file locks. But for now I am working!
 
Back
Top Bottom