FileIOPermissionAttribute - how to use it

[Guest]

Hi,

I have a question concerning the usage of the FileIOPermissionAttribute. I
have an assembly (essentially a loader) which reads files, does stuff with
the contents and writes records to an SQL database. The paths to the files
on which it operates are passed as parameters on a method within the assembly.

I'd like to be a diligent programmer and tie-down the security requirements
for the assembly. From the point of view of file IO, the requirements are as
follows:
1. Be able to read the contents of any file passed to the assembly method.
2. Not be able to write to any file, anywhere.

I cannot see how to achieve this with the FileIOPermissionAttribute. All of
the examples that I can find show IO permission being granted or denied to
explicit, hard-coded files or paths, eg:
[FileIOPermission(SecurityAction.Assert, Read="c:\\")]

This sort of thing doesn't strike me as being very useful for an attribute
at the assembly, class or method level. It requires the path or file-name to
be hard-coded, akin to having hard-coded paths and names in normal code.

If I want to specify read-access to any local file or deny write access to
any local file, I seem to need to know the layout of the drives of the target
machine at compile time. Obviously I don't know this. E.g. does a
particular target machine have a local C drive, or local C & D drives, or has
the owner been particularly strange and re-arranged the drive mappings so
that the local drives are C and H etc.

So my question is this: Is there a more general means available to allow
the programmer to specify the file IO requirements via the
FileIOPermissionAttribute when the layout of the target file-system is not
know at compile time?

Regards
David Razzetti

 

[Nicole Calinoiu]

I cannot see how to achieve this with the FileIOPermissionAttribute. All
of
the examples that I can find show IO permission being granted or denied to
explicit, hard-coded files or paths, eg:
[FileIOPermission(SecurityAction.Assert, Read="c:\\")]

At the method level, you can use imperative rather than declarative
permission forms, and the former support runtime specification of the path.
e.g.:

new FileIOPermission(FileIOPermissionAccess.Read, path).Assert();

This sort of thing doesn't strike me as being very useful for an attribute
at the assembly, class or method level. It requires the path or file-name
to
be hard-coded, akin to having hard-coded paths and names in normal code.

At the assembly level, only declarative permissions are possible. In .NET
2.0, FileIOPermissionAttribute is equipped with AllFiles and AllLocalFiles
properties. However, in 1.x, you're pretty much stuck making a
RequestOptional for unrestricted read permissions, which will at least allow
administrators to restrict your assembly's permissions as they desire
without preventing it from loading.