qzrlsd

Hi,

I've got myself very confused about the usage of the FileIOPermission.Demand method. For example;

If I supply a path that I do not have "write" permissions to via ACL:

FileIOPermission fileIOPermission = new FileIOPermission(FileIOPermissionAccess.Write, @"\\server\path\path2\path3");

fileIOPermission.Demand();

The demand does not fail as I expected. I've search the forum and found the following:

http://forums.microsoft.com/MSDN/ShowPost.aspx PostID=149239&SiteID=1

I amended my code to no avail.

I've obviously got the wrong end of the stick about how this works! I was assuming it worked by looking at the permissions on the folder or file. Does it just evaulate the assembly evidence So if I'm running in "Full Trust" it will pass the demand Please help.....



Re: Common Language Runtime FileIOPermission ACL Question

Mark Benningfield

Hello All.

qzrlsd:

Assuming that I understand you correctly, then you're laboring under what seems to be a common mis-conception about security permissions.

The Demand() method checks to see that callers TO the immediate stack frame have the permission in question. The resonders in the post you linked to explained the what and why, but perhaps didn't notice the initial mis-conception.

To illustrate:

If you have a method called ThisMethod, and a permission object in that method that calls Demand(), then the Demand() method will check to see if code that calls ThisMethod has the permission in question. If there is no code on the call stack, then Demand() does not fail, because there are no callers to check.

If you want to see if your assembly has the permission, then you have to put the Demand() method in code that is called, so that there is code on the call stack. So, if you put the permission object and its call to Demand() in a method called ThatMethod, and call ThatMethod from ThisMethod, then if your assembly does not have the permission, Demand() will fail.

HTH.






Re: Common Language Runtime FileIOPermission ACL Question

qzrlsd

Hi Mark,

Thanks for the reply. I think I understand about the evaulation of the permission. I guess my question really is: Does the FileIOPermission check the ACL of the folder or file. Or does it simply check that the code group the assembly is running in would be able to access the folder or file





Re: Common Language Runtime FileIOPermission ACL Question

Mark Benningfield

Hello All.

qzrlsd:

Neither. ACL security is role-based, generally speaking. If you attempt to access a file that is ACL-protected, then what you get is an UnauthorizedAccessException, which is thrown by the OS, not the CLR, if I'm not mistaken.

HTH.






Re: Common Language Runtime FileIOPermission ACL Question

qzrlsd

Now I'm really confused :) I know I'm probably being thick!

What is the purpose of the FileIOPermission

The documentation found here: http://msdn2.microsoft.com/en-us/library/system.security.permissions.fileiopermission.aspx

FileIOPermission describes protected operations on files and folders. The File class helps provide secure access to files and folders. The security access check is performed when the handle to the file is created. By doing the check at creation time, the performance impact of the security check is minimized. Opening a file happens once, while reading and writing can happen multiple times. Once the file is opened, no further checks are done. If the object is passed to an untrusted caller, it can be misused. For example, file handles should not be stored in public global statics where code with less permission can access them.





Re: Common Language Runtime FileIOPermission ACL Question

Mark Benningfield

Hello All.

qzrlsd:

You're dealing with 2 different security models, ACL and CAS. What makes it more complicated is that there doesn't seem to be any consensus on, or even any interest in, establishing a convention for terms.

Think of it like this. Code Access Security deals with permissions. Access Control Lists deal with privileges. Executable code assemblies (and code groups) have permissions. Users (and user groups) have privileges. Permissions are granted by the CLR and/or modified by Admins. Privileges are granted by the OS, and/or modified by Admins. Permissions are applicable to managed code. Privileges are applicable to the whole operating system.

The FileIOPermission class deals with CAS permissions on executable assemblies. Even if an assembly is running with Full Trust granted by the CLR, if the assembly is being run by a user with limited privileges, it's a no-go.

For example, MS Word, installed locally, runs under Full Trust. Assemblies installed on the local disk run under Full Trust by default. Okay, if UserGeorge has encrypted a Word document he created -- through the File Properties dialog in the Shell -- then an ACL is created by the OS through the NTFS. If UserJane, with a limited user account, running MS Word, tries to open UserGeorge's Word document, an UnauthorizedAccessException is thrown, because she doesn't have the required access privilege for that file. A SecurityException is not thrown, because MS Word has unrestricted FileIOPermission from the CLR.

That's the way I understand the situation so far. I make no claims to being an expert on either security model, but I have been studying the CAS model recently, because it was giving me a major headache every time I ran into it. I'm still studying, though, so if a MSFT shows up and says that I'm full of it, believe it.

HTH.






Re: Common Language Runtime FileIOPermission ACL Question

qzrlsd

Hi Mark,

I do see what you are saying. Thanks for the response. What you are saying makes sense because you can create a File IO Permission Set and provide a path.

Cheers





Re: Common Language Runtime FileIOPermission ACL Question

KayaksTheAtlantic

I think I understand so far, but have a related question.

Say for example I am writing a new version of notepad. When I open the file, I only want read access. But I want to disable the File Save menu item if the user is not going to have permission to write the file anyhow. The actual situation is a bit more complicated, but it is similar. The File class does not seem to help me until I actually want to write the file. The FileAttributes.ReadOnly flag helps some, but doesn't tell me anything about ACL permissions or if the file is on a networked drive that is shared ReadOnly. I would think ACL would help, but I cannot figure out how to use the ACL class to do this check.





Re: Common Language Runtime FileIOPermission ACL Question

Mark Benningfield

Hello All.

KayaksTheAtlantic:

I'm not trying to put you off, but new questions should be posted by starting a new thread in the applicable forum. Try this one in the Base Class Library forum.

HTH.