> I have written a C# 2.0 application which writes to (creates subkeys and
> data values) in the registry under HLM\SOFTWARE. This application works
> fine when logged in as admin. But it fails when logged into another
> (non-admin) account. Of course, this is what I expect.
>
> However, I am looking for a way, upon program start, for the system to
> look at my program, see what permissions it requires, and terminate
> (with some warning) if the current user context does not fulfill one or
> more security requirement.
>
> It seems like this should be easy to do. But no matter what, the program
> runs until a call is made to modify the registry and then throws a
> security exception. I really don't want my program to run at all unless
> it will be able to succeed in diddling the registry.
>
> I have tried the following in the main executable's assemblyinfo file
> (note, however, that the method which modifies the registry is in
> another assembly):
>
> [assembly: RegistryPermissionAttribute(SecurityAction.RequestMinimum,
>     All = "HKEY_LOCAL_MACHINE\\SOFTWARE")]
>
> The above is almost verbatim from the docs for
> RegistryKey.CreateSubKey(). Since this is an attribute of the main
> program's assembly, I'd think the runtime should see this, check it
> against the current context, and see that the non-admin user will NOT be
> granted permission. With this knowledge, I'd think the runtime would not
> permit the executable to run.
>
> But I guess that something could be done dynamically which changes
> things so it will succeed. So maybe the runtime cannot do this
> automatically and I have to do something myself.
>
> What is the best way to achieve this? Thanks for looking/responding.

"David White" <whitedav***@comcast.net> wrote in message
news:%23tkz2q1qGHA.4424@TK2MSFTNGP05.phx.gbl...
>I should have also mentioned that I also tried annotating my program's
>main() with the following:
>
> [RegistryPermission(SecurityAction.Demand, Unrestricted = true)]
>
> The program doesn't get stopped here either. It runs until the attempt is
> made to actually modify the registry and then fails if the user is
> non-admin. Thanks.
>
> David White wrote:
>> I have written a C# 2.0 application which writes to (creates subkeys and
>> data values) in the registry under HLM\SOFTWARE. This application works
>> fine when logged in as admin. But it fails when logged into another
>> (non-admin) account. Of course, this is what I expect.
>>
>> However, I am looking for a way, upon program start, for the system to
>> look at my program, see what permissions it requires, and terminate (with
>> some warning) if the current user context does not fulfill one or more
>> security requirement.
>>
>> It seems like this should be easy to do. But no matter what, the program
>> runs until a call is made to modify the registry and then throws a
>> security exception. I really don't want my program to run at all unless
>> it will be able to succeed in diddling the registry.
>>
>> I have tried the following in the main executable's assemblyinfo file
>> (note, however, that the method which modifies the registry is in another
>> assembly):
>>
>> [assembly: RegistryPermissionAttribute(SecurityAction.RequestMinimum,
>>     All = "HKEY_LOCAL_MACHINE\\SOFTWARE")]
>>
>> The above is almost verbatim from the docs for
>> RegistryKey.CreateSubKey(). Since this is an attribute of the main
>> program's assembly, I'd think the runtime should see this, check it
>> against the current context, and see that the non-admin user will NOT be
>> granted permission. With this knowledge, I'd think the runtime would not
>> permit the executable to run.
>>
>> But I guess that something could be done dynamically which changes things
>> so it will succeed. So maybe the runtime cannot do this automatically and
>> I have to do something myself.
>>
>> What is the best way to achieve this? Thanks for looking/responding.

> This looks like a confusion between Windows security and code access
> security.  You are being denied access to the registry based on the
> user the logged in, not based on the identity of the code that is
> trying to do the registry operation.  The permissions that you are
> trying to use are for code access security.  In your case, your code
> likely has full trust since it is run locally, so those demands would
> actually work.
>
> The is compounded by a design "variance" in MS's implementation of the
> registry classes, where they throw a SecurityException when they
> should throw the standard UnauthorizedAccessException.  This makes the
> problem look like CAS, when it is Windows related.
>
> To actually know whether Windows will allow the requested registry
> mods, you need to call the Windows AccessCheck function via p/invoke.
> There isn't an easy way to do this in .NET besides simply catching the
> exception that is thrown when you try it.
>
> Joe K.
>

> as Joe said, you ca try to access the resource and catch the exception...
>
> or you can check if the current user is an administrator with this code:
>
> if (new
> WindowsPrincipal(WindowsIdentity.GetCurrent()).IsInRole(WindowsBuiltInRole.Administrators))
>
> {}
>
>
>
>> This looks like a confusion between Windows security and code access
>> security.  You are being denied access to the registry based on the
>> user the logged in, not based on the identity of the code that is
>> trying to do the registry operation.  The permissions that you are
>> trying to use are for code access security.  In your case, your code
>> likely has full trust since it is run locally, so those demands would
>> actually work.
>>
>> The is compounded by a design "variance" in MS's implementation of the
>> registry classes, where they throw a SecurityException when they
>> should throw the standard UnauthorizedAccessException.  This makes the
>> problem look like CAS, when it is Windows related.
>>
>> To actually know whether Windows will allow the requested registry
>> mods, you need to call the Windows AccessCheck function via p/invoke.
>> There isn't an easy way to do this in .NET besides simply catching the
>> exception that is thrown when you try it.
>>
>> Joe K.
>>
>
>

> Thanks for all the responses. I would guess that an administrator
> could give other users the ability to changes this part of the
> registry (not sure how, maybe the local policy editor). So rather than
> test for the user being in the admin role, I will follow Joe's advice.
> Cheers!
>
> Dominick Baier wrote:
>
>> as Joe said, you ca try to access the resource and catch the
>> exception...
>>
>> or you can check if the current user is an administrator with this
>> code:
>>
>> if (new
>> WindowsPrincipal(WindowsIdentity.GetCurrent()).IsInRole(WindowsBuiltI
>> nRole.Administrators))
>>
>> {}
>>
>>> This looks like a confusion between Windows security and code access
>>> security.  You are being denied access to the registry based on the
>>> user the logged in, not based on the identity of the code that is
>>> trying to do the registry operation.  The permissions that you are
>>> trying to use are for code access security.  In your case, your code
>>> likely has full trust since it is run locally, so those demands
>>> would actually work.
>>>
>>> The is compounded by a design "variance" in MS's implementation of
>>> the registry classes, where they throw a SecurityException when they
>>> should throw the standard UnauthorizedAccessException.  This makes
>>> the problem look like CAS, when it is Windows related.
>>>
>>> To actually know whether Windows will allow the requested registry
>>> mods, you need to call the Windows AccessCheck function via
>>> p/invoke. There isn't an easy way to do this in .NET besides simply
>>> catching the exception that is thrown when you try it.
>>>
>>> Joe K.
>>>

"David White" <whitedav***@comcast.net> wrote in message
news:%23$NwO93qGHA.3256@TK2MSFTNGP04.phx.gbl...
> Thanks for all the responses. I would guess that an administrator could
> give other users the ability to changes this part of the registry (not
> sure how, maybe the local policy editor). So rather than test for the user
> being in the admin role, I will follow Joe's advice. Cheers!
>
> Dominick Baier wrote:
>
>> as Joe said, you ca try to access the resource and catch the exception...
>>
>> or you can check if the current user is an administrator with this code:
>>
>> if (new
>> WindowsPrincipal(WindowsIdentity.GetCurrent()).IsInRole(WindowsBuiltInRole.Administrators))
>> {}
>>
>>
>>
>>> This looks like a confusion between Windows security and code access
>>> security.  You are being denied access to the registry based on the
>>> user the logged in, not based on the identity of the code that is
>>> trying to do the registry operation.  The permissions that you are
>>> trying to use are for code access security.  In your case, your code
>>> likely has full trust since it is run locally, so those demands would
>>> actually work.
>>>
>>> The is compounded by a design "variance" in MS's implementation of the
>>> registry classes, where they throw a SecurityException when they
>>> should throw the standard UnauthorizedAccessException.  This makes the
>>> problem look like CAS, when it is Windows related.
>>>
>>> To actually know whether Windows will allow the requested registry
>>> mods, you need to call the Windows AccessCheck function via p/invoke.
>>> There isn't an easy way to do this in .NET besides simply catching the
>>> exception that is thrown when you try it.
>>>
>>> Joe K.
>>>
>>