Re: SecurityAction RequestOptional, RequestRefuse, & more
- From: "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com>
- Date: Sun, 12 Jun 2005 08:22:18 -0400
"David Thielen" <thielen@xxxxxxxxxxxxx> wrote in message
news:D89767ED-7789-4247-9760-CA6269C8AEF7@xxxxxxxxxxxxxxxx
> Thank you - this helps a ton.
>
> I have a DLL that other apps call and I wanted to be very specific about
> exactly it did so users could see what access it needs. However it has an
> event that other DLLs can register with and when that event fires, my DLL
> is
> in the call stack.
>
> So it looks like I should only declare RequestMinimum and leave the
> RequestOptional to the default FullTrust.
Actually, that's not strictly necessary. If you want to allow your assembly
to run with full trust while still using RequestOptional attributes for the
purpose of providing information to consumers and/or CAS admins, just add a
RequestOptional for unrestricted permissions (full trust) in addition to
your existing assembly-level permission attributes. e.g.:
[assembly: PermissionSet(SecurityAction.RequestOptional, Unrestricted =
true)]
> I was assuming more functionality
> than exists in the security model.
Actually, you were assuming _different_ (an perhaps even less)
functionality. RequestOptional simply has side effects that you weren't
expecting, and one could very well argue that the option is poorly named
because of this. However, the "unexpected" functionality that it exposes is
quite useful, and at least some of us do take advantage of it in order to
use white-listing rather than black-listing in our permissions declarations.
>
> --
> thanks - dave
>
>
> "Nicole Calinoiu" wrote:
>
>> "David Thielen" <thielen@xxxxxxxxxxxxx> wrote in message
>> news:739B3E4F-64C7-4AD2-B9F9-3433D76B74A8@xxxxxxxxxxxxxxxx
>> <snip>
>> > But what about a permission that my DLL does not need - but I want to
>> > allow
>> > in the delegates. Is there any way to set that? It seems that would be
>> > useful
>> > information.
>>
>> Assertion is the usual way for bypassing permission limitations imposed
>> elsewhere on the call stack (whether due to limited permission grants or
>> constraining stack walk modifiers). However, as I mentioned in your
>> earlier
>> thread, assertion is potentially dangerous, and I wouldn't recommend its
>> use
>> until you understand those dangers thoroughly and know how to protect
>> against potential luring attacks.
>>
>>
>> > It also seems that not listing a specific permission is the same as
>> > saying
>> > RequestOptional???
>>
>> Not at all. I would once again encourage you to read Shawn Farkas'
>> coverage
>> of this topic at
>> http://blogs.msdn.com/shawnfa/archive/2004/08/30/222918.aspx if you are
>> interested in understanding how the three varieties of assembly-level
>> permission attributes work together.
>>
>>
>> >
>> > --
>> > thanks - dave
>>
>>
>>
.
- References:
- SecurityAction RequestOptional, RequestRefuse, & more
- From: David Thielen
- Re: SecurityAction RequestOptional, RequestRefuse, & more
- From: Nicole Calinoiu
- Re: SecurityAction RequestOptional, RequestRefuse, & more
- From: David Thielen
- SecurityAction RequestOptional, RequestRefuse, & more
- Prev by Date: Re: GC Question
- Next by Date: The debugger in vb.net 1.1 doesn't show correctly the execution pa
- Previous by thread: Re: SecurityAction RequestOptional, RequestRefuse, & more
- Next by thread: Group IV TIFF image
- Index(es):
Relevant Pages
|
