Hi,

If CAS policy is setup to deny an assembly ANC the permission
FileIOPermission, then if the assembly attempts to do File IO, the .NET
FW assembly that handles file IO should catch it, right? It shouldn't
be necesarry to put a check for FileIOPermission in the assembly
itself, and would seem to degrade performance because the check is
already going to be done further down the call stack, but the .NET FW
assembly. Plus any assembly wanting to do naughty file IO would just
skip its own demand anyway?

Or is it better to be  explicit about what permissions an assembly
needs, and put an attribute in the assembly to show it does a demand on
FileIOPermission? (even though it's redundent).

Thanks,

Jon Paugh

Yes, as long as the calls go through framework code paths that demand
FileIOPermission.


Not if there's already a "downstream" demand.


There's really no need to duplicate permission demands in this way.  If you
want to communicate your assembly's minimum required permission set,
consider using assembly-level RequestMinimum permission attributes instead.

In general, one only makes CAS permission demands in code that makes
assertions and/or defines or extends a resource that requires protection.
In practice, most of the latter also make assertions (usually for permission
to call into unmanaged code), so most projects aren't likely to need
permission demands that aren't coupled with assertions.  Then again, since
most projects shouldn't need assertions, they probably shouldn't need any
explicit demands for CAS permissions either... ;)

Thanks for the response Nicole.

Client/Server application with single login-SecureStream?
Securing a .NET webapp with ActiveDir and SQL-server?
How can I access more properties of the AD Acount
encrypting app.config with RSA
Application Security and Trust
Mail merge with an MD5 hash.
Directory access check
Kerberos S4U problem
SHA1Managed class has different results in 2.0 vs. 1.1??
LogParser - Error