"chuck rudolph" wrote:

> In the page_load, I have the following code:
> PermissionSet ps = new PermissionSet(PermissionState.None);
> ps.AddPermission(new EventLogPermission
> EventLogPermissionAccess.Instrument,"."));
> ps.Demand();
> EventLogPermission ps2 = (EventLogPermission)
> ps.GetPermission(typeof(EventLogPermission));
>
> foreach (EventLogPermissionEntry psx in ps2.PermissionEntries)
> {
>     this.Response.Write("<p> Machine: " +
>     psx.MachineName + " Bits: " + psx.PermissionAccess + " </p>");
> }
>
> When executed it writes:
> Machine: . Bits: Instrument
>
> Which would lead me to believe that I can write to an event log. But when I
> then try to execute these two lines of code:
>
> EventLog el = new EventLog("My Log",".","Login Category");
> el.WriteEntry("Login is getting ready to run!");
>
> ASP.Net (Microsoft .NET Framework Version:1.1.4322.2032) throws the
> following exception:
> Exception Details: System.Security.SecurityException: Requested registry
> access is not allowed.
>
> Any ideas?
>
>
>

"chuck rudolph" wrote:

> Here's some more info that may help my helpers ---
>
> The error occurs when this code runs as an anonymous user. If I add an
> identity element to web.config and impersonate a "user" all is well as long
> as I give the user NTFS write access to .net\framework\ver\temporary asp.net
> files\ directory.
>
> My read of the doc did not lead me this way, but I got to thinking that
> there might be a "deny" access policy somewhere in the tree and gave it a try.
>
> So what is the "best practice" recommendation for a web applicaton that
> allows anonymous users (mine uses forms authentication via a sql server ) and
> needs to write to an event log?
>
> Thanks...Chuck
>
> "chuck rudolph" wrote:
>
> > In the page_load, I have the following code:
> > PermissionSet ps = new PermissionSet(PermissionState.None);
> > ps.AddPermission(new EventLogPermission
> > EventLogPermissionAccess.Instrument,"."));
> > ps.Demand();
> > EventLogPermission ps2 = (EventLogPermission)
> > ps.GetPermission(typeof(EventLogPermission));
> >
> > foreach (EventLogPermissionEntry psx in ps2.PermissionEntries)
> > {
> >     this.Response.Write("<p> Machine: " +
> >     psx.MachineName + " Bits: " + psx.PermissionAccess + " </p>");
> > }
> >
> > When executed it writes:
> > Machine: . Bits: Instrument
> >
> > Which would lead me to believe that I can write to an event log. But when I
> > then try to execute these two lines of code:
> >
> > EventLog el = new EventLog("My Log",".","Login Category");
> > el.WriteEntry("Login is getting ready to run!");
> >
> > ASP.Net (Microsoft .NET Framework Version:1.1.4322.2032) throws the
> > following exception:
> > Exception Details: System.Security.SecurityException: Requested registry
> > access is not allowed.
> >
> > Any ideas?
> >
> >
> >

"chuck rudolph" wrote:

> Joseph (& Nicole), Thanks. Joeseph's words on the application log do work. I
> need to attempt a like fix to my custom log file and see if I can make it
> work. I will post a solution if I find one.
>
> On the other side of the coin, does anyone know why the permissionSet.Demand
> (or Assert) complete normally -- leading me to believe that I can create the
> log and log source?
>
> Thanks...Chuck
>
>

"Joseph MCAD" wrote:

>
>   April 5, 2005
>
>     Hi Chuck,
>
>        What permissions are in the permissionset that you are
> demanding/asserting? If you talking about the Eventlogpermission, it is
> working, because you are granted that permission. Just to let you know... If
> you are granted FullTrust then NO permission demands will even be evaluated.
> That permission set BYPASSES checks of all kinds, even if they are for custom
> permissions that you have not granted that assembly. This could be why your
> permissionset is completing, but you should be able to access the eventlog
> without failing, so I don't think so. If you want to be granted all normal,
> builtin permissions, while STILL evaluating demands/asserts/etc. then you
> should run not under FullTrust but Everything. Everything will grant you all
> normal, builtin permissions while still evaluating CAS. I hope this helps and
> be sure to post about your custom log and the registry. Thanks, you are
> saving me the experiment!
>
>                                                                             
>             Joseph MCAD
>
>
>
> "chuck rudolph" wrote:
>
> > Joseph (& Nicole), Thanks. Joeseph's words on the application log do work. I
> > need to attempt a like fix to my custom log file and see if I can make it
> > work. I will post a solution if I find one.
> >
> > On the other side of the coin, does anyone know why the permissionSet.Demand
> > (or Assert) complete normally -- leading me to believe that I can create the
> > log and log source?
> >
> > Thanks...Chuck
> >
> >

"chuck rudolph" wrote:

> Joesph, The reason I am confused is the code first "demanded" a permission
> set of EventLogPermissionAccess.Instrument. MSDN says "The EventLog can read
> or write to existing logs, and create event sources and logs." The demand
> succeeded. That to me says that I have the rights to (1) create event logs
> and (2) create event sources and (3) read and write logs. We both know that
> is not true, so what part of this don't I get. (The actual code that I ran is
> listed at the beginning of the first post. I start with "none", although the
> task is running with "full")
>
> Thanks. (BTW: the test worked, see the main line post.) ...Chuck
>
> "Joseph MCAD" wrote:
>
> >
> >   April 5, 2005
> >
> >     Hi Chuck,
> >
> >        What permissions are in the permissionset that you are
> > demanding/asserting? If you talking about the Eventlogpermission, it is
> > working, because you are granted that permission. Just to let you know... If
> > you are granted FullTrust then NO permission demands will even be evaluated.
> > That permission set BYPASSES checks of all kinds, even if they are for custom
> > permissions that you have not granted that assembly. This could be why your
> > permissionset is completing, but you should be able to access the eventlog
> > without failing, so I don't think so. If you want to be granted all normal,
> > builtin permissions, while STILL evaluating demands/asserts/etc. then you
> > should run not under FullTrust but Everything. Everything will grant you all
> > normal, builtin permissions while still evaluating CAS. I hope this helps and
> > be sure to post about your custom log and the registry. Thanks, you are
> > saving me the experiment!
> >
> >                                                                             
> >             Joseph MCAD
> >
> >
> >
> > "chuck rudolph" wrote:
> >
> > > Joseph (& Nicole), Thanks. Joeseph's words on the application log do work. I
> > > need to attempt a like fix to my custom log file and see if I can make it
> > > work. I will post a solution if I find one.
> > >
> > > On the other side of the coin, does anyone know why the permissionSet.Demand
> > > (or Assert) complete normally -- leading me to believe that I can create the
> > > log and log source?
> > >
> > > Thanks...Chuck
> > >
> > >

"Joseph MCAD" wrote:

>
>    April 5, 2005
>
>      I see the permission set you mean. This confusion is well founded. What
> is happening is when you demand the eventlogpermission.instrument it
> succeeds, because you are granted that permission. BUT when you go to call
> eventlog.createventsource, the CreateEventSource method secretly demands the
> FullTrust permission set. It would be as if I created this following method
> in a custom library for you to use:
>
> <FileIoPermission(SecurityAction.Demand, all:="c:\myfolder")> _
> Public Sub DoWorkForYou()
>     
>     ' Before doing work, secretly demand UNRESTRICTED access to file system,
> EVEN Though the security attribute above only asks for c:\myfolder
>
>    dim permset as new FileIoPermission(PermissionState.Unrestricted)     
>    permset.Demand 'Secretly Demands Unrestricted FileIOPermission
>
>    'Now do promised work
> End Sub
>
> If you ran permview to analyze the requested minimum permissions, then it
> would look like you just have to be able to access c:\myfolder. You would be
> granted access to this method. However, the method Secretly demands the
> unrestricted FileIOPermission IN the method and therefore is not displayed by
> permview. This causes the confusion and explains why some methods work and
> some don't even though you Should be able to access them all. I hope this
> makes sense and thanks for reporting the result of the experiment! :-)
>
>                                                                             
>            Joseph MCAD
>
>
> "chuck rudolph" wrote:
>
> > Joesph, The reason I am confused is the code first "demanded" a permission
> > set of EventLogPermissionAccess.Instrument. MSDN says "The EventLog can read
> > or write to existing logs, and create event sources and logs." The demand
> > succeeded. That to me says that I have the rights to (1) create event logs
> > and (2) create event sources and (3) read and write logs. We both know that
> > is not true, so what part of this don't I get. (The actual code that I ran is
> > listed at the beginning of the first post. I start with "none", although the
> > task is running with "full")
> >
> > Thanks. (BTW: the test worked, see the main line post.) ...Chuck
> >
> > "Joseph MCAD" wrote:
> >
> > >
> > >   April 5, 2005
> > >
> > >     Hi Chuck,
> > >
> > >        What permissions are in the permissionset that you are
> > > demanding/asserting? If you talking about the Eventlogpermission, it is
> > > working, because you are granted that permission. Just to let you know... If
> > > you are granted FullTrust then NO permission demands will even be evaluated.
> > > That permission set BYPASSES checks of all kinds, even if they are for custom
> > > permissions that you have not granted that assembly. This could be why your
> > > permissionset is completing, but you should be able to access the eventlog
> > > without failing, so I don't think so. If you want to be granted all normal,
> > > builtin permissions, while STILL evaluating demands/asserts/etc. then you
> > > should run not under FullTrust but Everything. Everything will grant you all
> > > normal, builtin permissions while still evaluating CAS. I hope this helps and
> > > be sure to post about your custom log and the registry. Thanks, you are
> > > saving me the experiment!
> > >
> > >                                                                             
> > >             Joseph MCAD
> > >
> > >
> > >
> > > "chuck rudolph" wrote:
> > >
> > > > Joseph (& Nicole), Thanks. Joeseph's words on the application log do work. I
> > > > need to attempt a like fix to my custom log file and see if I can make it
> > > > work. I will post a solution if I find one.
> > > >
> > > > On the other side of the coin, does anyone know why the permissionSet.Demand
> > > > (or Assert) complete normally -- leading me to believe that I can create the
> > > > log and log source?
> > > >
> > > > Thanks...Chuck
> > > >
> > > >

> That permission set BYPASSES checks of all kinds, even if they are for
> custom
> permissions that you have not granted that assembly.  This could be why
> your
> permissionset is completing, but you should be able to access the eventlog
> without failing, so I don't think so. If you want to be granted all
> normal,
> builtin permissions, while STILL evaluating demands/asserts/etc. then you
> should run not under FullTrust but Everything. Everything will grant you
> all
> normal, builtin permissions while still evaluating CAS. I hope this helps
> and
> be sure to post about your custom log and the registry. Thanks, you are
> saving me the experiment!
>
>
>            Joseph MCAD
>
>
>
> "chuck rudolph" wrote:
>
>> Joseph (& Nicole), Thanks. Joeseph's words on the application log do
>> work. I
>> need to attempt a like fix to my custom log file and see if I can make it
>> work. I will post a solution if I find one.
>>
>> On the other side of the coin, does anyone know why the
>> permissionSet.Demand
>> (or Assert) complete normally -- leading me to believe that I can create
>> the
>> log and log source?
>>
>> Thanks...Chuck
>>
>>

>
> Thanks...Chuck
>
>

"Nicole Calinoiu" wrote:
> The problem was caused purely by the user not having adequate permissions to
> the registry key under Windows security settings.  Code access security was
> not involved in this particular failure.  Your confusion is probably at
> least partially caused by the fact that a SecurityException (which is
> supposed to be associated with CAS permission failures) was thrown instead
> of an UnauthorizedAccessException.  The latter would be more appropriate in
> this case, but that's unfortunately not how the relevant method was
> implemented.

"chuck rudolph" <chuckrudo***@discussions.microsoft.com> wrote in message
news:37C456C2-6558-4320-8C8C-84D06D8424C9@microsoft.com...
> Nicole, I can buy what you say about the failing being related to windows
> security and not CAS because when I impersonate the administrator it works
> just peachy. But I can not find what windows security needs to be set
> where.
> I figured if I changed the "permissions" on the event log in the regedit I
> could write to the registry. But selecting both IUser_ and ASP.NET (I'm on
> XP) do not let me write to the event log.
>
> Further I have found that depending on the name of the log file I create,
> I
> can either read/write it or not. This part is really confusing. (All the
> names are 8 characters or less) I can't find a rhyme or reason to which
> name
> will let a web application read/write and which name will throw an error
> in
> the web application.
>
> ...Chuck
>
> "Nicole Calinoiu" wrote:
>> The problem was caused purely by the user not having adequate permissions
>> to
>> the registry key under Windows security settings.  Code access security
>> was
>> not involved in this particular failure.  Your confusion is probably at
>> least partially caused by the fact that a SecurityException (which is
>> supposed to be associated with CAS permission failures) was thrown
>> instead
>> of an UnauthorizedAccessException.  The latter would be more appropriate
>> in
>> this case, but that's unfortunately not how the relevant method was
>> implemented.
>

"Joseph MCAD" wrote:

>
> April 6, 2005
>
>    I once read in my security book how to configure the NTFS permissions on
> the eventlog class, but I never got around to trying it. I just looked it
> back up and appearently the process account (ASPNET) needs to have these
> permissions granted to it on the key below to create eventsources:
>
> hkey_local_machine\system\currentcontrolset\services\eventlog
>
>  You need to grant ASPNET on this key the following permissions:  (you will
> have to get into the advanced permission settings)
>
> Query Value
> Set Value
> Create SubKey
> Enumerate SubKeys
> Notify
> Read
>
> If you try this, be sure to let me know the outcome! :-)
>
>
>                                                                             
>                        Joseph MCAD
>
>
>

"chuck rudolph" <chuckrudo***@discussions.microsoft.com> wrote in message
news:37C456C2-6558-4320-8C8C-84D06D8424C9@microsoft.com...
> Nicole, I can buy what you say about the failing being related to windows
> security and not CAS because when I impersonate the administrator it works
> just peachy. But I can not find what windows security needs to be set
> where.
> I figured if I changed the "permissions" on the event log in the regedit I
> could write to the registry. But selecting both IUser_ and ASP.NET (I'm on
> XP) do not let me write to the event log.
>
> Further I have found that depending on the name of the log file I create,
> I
> can either read/write it or not. This part is really confusing. (All the
> names are 8 characters or less) I can't find a rhyme or reason to which
> name
> will let a web application read/write and which name will throw an error
> in
> the web application.
>
> ...Chuck
>

"Joe Kaplan (MVP - ADSI)" wrote:

> I'd highly recommend using regmon and filemon to find which file or key is
> getting the access denied and figure out which account is causing the
> problem.  Then, if that doesn't give you enough information to fix the
> issue, enable object auditing in local security policy and set the SACL on
> the object in question to enable audits.  Then the security event log will
> give you more details.
>
> I got lost on the last exchange though.  Are you still having trouble
> creating event sources from ASP.NET or just writing to them?  Generally, you
> create your event sources during deployment with an admin account to avoid
> these issues.  However, if the application itself can't write to the log,
> then that is a different problem.
>
> Joe K.
>

"Joe Kaplan (MVP - ADSI)" wrote:

> I'd highly recommend using regmon and filemon to find which file or key is
> getting the access denied and figure out which account is causing the
> problem.  Then, if that doesn't give you enough information to fix the
> issue, enable object auditing in local security policy and set the SACL on
> the object in question to enable audits.  Then the security event log will
> give you more details.
>
> I got lost on the last exchange though.  Are you still having trouble
> creating event sources from ASP.NET or just writing to them?  Generally, you
> create your event sources during deployment with an admin account to avoid
> these issues.  However, if the application itself can't write to the log,
> then that is a different problem.
>
> Joe K.
>

>
> Thanks to everyone for the help...Chuck
>
> "Joe Kaplan (MVP - ADSI)" wrote:
>
>> I'd highly recommend using regmon and filemon to find which file or key
>> is
>> getting the access denied and figure out which account is causing the
>> problem.  Then, if that doesn't give you enough information to fix the
>> issue, enable object auditing in local security policy and set the SACL
>> on
>> the object in question to enable audits.  Then the security event log
>> will
>> give you more details.
>>
>> I got lost on the last exchange though.  Are you still having trouble
>> creating event sources from ASP.NET or just writing to them?  Generally,
>> you
>> create your event sources during deployment with an admin account to
>> avoid
>> these issues.  However, if the application itself can't write to the log,
>> then that is a different problem.
>>
>> Joe K.
>>
>

"chuck rudolph" <chuckrudo***@discussions.microsoft.com> wrote in message
news:7B45333E-C3CD-4F6B-8062-F500A08B1963@microsoft.com...
> Joe, Regmon did the trick. The security event log on my development
> machine
> on had ONLY two defined members that allowed access -- administrators and
> system both with special. So your average guy could not read the security
> registery and that's where the error was being thrown. If the log file
> name
> "sorted" before security, aspnet found what it was looking for and wrote
> the
> log entry. Otherwise, it tried to look in the security log and got booted.
> Adding "read" access for the asp.net worker process solved the problem. In
> checking another pc, it looks like ordinary "users" should have read
> access.
>
> Thanks to everyone for the help...Chuck
>
> "Joe Kaplan (MVP - ADSI)" wrote:
>
>> I'd highly recommend using regmon and filemon to find which file or key
>> is
>> getting the access denied and figure out which account is causing the
>> problem.  Then, if that doesn't give you enough information to fix the
>> issue, enable object auditing in local security policy and set the SACL
>> on
>> the object in question to enable audits.  Then the security event log
>> will
>> give you more details.
>>
>> I got lost on the last exchange though.  Are you still having trouble
>> creating event sources from ASP.NET or just writing to them?  Generally,
>> you
>> create your event sources during deployment with an admin account to
>> avoid
>> these issues.  However, if the application itself can't write to the log,
>> then that is a different problem.
>>
>> Joe K.
>>
>

> You must go to your command
> prompt and open the registry editor to set this up. Type "regedit" at the
> command prompt. Go to:
> HKEY_Local_Machine\SYSTEM\CurrentControlSet\Services\EventLog\Application
>
> Create a new node under the Application node. Name this new node the name
> of
> your web application. If your application is named Northwind or MySite,
> then
> name this new node exactly as your site. You can then use the
> Diagnostics.EventLog class as long as you do not create event sources. By
> modifying the registry in this way, you pre-made the event source. Just
> make
> sure to set the source property on the eventlog class to the name of your
> web
> application. Keep in mind that you might not be able to do this for the
> Security or System eventlogs. I have found it only works under the
> Application (I haven't tried a custom log.) and also you cannot be
> "registered" by creating nodes under more than one log. Just make sure
> that
> your web application is granted the EventLogPermission with read/write
> access. You do not have to worry about the fulltrust demand anymore! Hope
> this helps and have a great day!
>
>
>
>   Joseph MCAD
>
>
>
> "chuck rudolph" wrote:
>
>> Here's some more info that may help my helpers ---
>>
>> The error occurs when this code runs as an anonymous user. If I add an
>> identity element to web.config and impersonate a "user" all is well as
>> long
>> as I give the user NTFS write access to .net\framework\ver\temporary
>> asp.net
>> files\ directory.
>>
>> My read of the doc did not lead me this way, but I got to thinking that
>> there might be a "deny" access policy somewhere in the tree and gave it a
>> try.
>>
>> So what is the "best practice" recommendation for a web applicaton that
>> allows anonymous users (mine uses forms authentication via a sql server )
>> and
>> needs to write to an event log?
>>
>> Thanks...Chuck
>>
>> "chuck rudolph" wrote:
>>
>> > In the page_load, I have the following code:
>> > PermissionSet ps = new PermissionSet(PermissionState.None);
>> > ps.AddPermission(new EventLogPermission
>> > EventLogPermissionAccess.Instrument,"."));
>> > ps.Demand();
>> > EventLogPermission ps2 = (EventLogPermission)
>> > ps.GetPermission(typeof(EventLogPermission));
>> >
>> > foreach (EventLogPermissionEntry psx in ps2.PermissionEntries)
>> > {
>> >     this.Response.Write("<p> Machine: " +
>> > psx.MachineName + " Bits: " + psx.PermissionAccess + " </p>");
>> > }
>> >
>> > When executed it writes:
>> > Machine: . Bits: Instrument
>> >
>> > Which would lead me to believe that I can write to an event log. But
>> > when I
>> > then try to execute these two lines of code:
>> >
>> > EventLog el = new EventLog("My Log",".","Login Category");
>> > el.WriteEntry("Login is getting ready to run!");
>> >
>> > ASP.Net (Microsoft .NET Framework Version:1.1.4322.2032) throws the
>> > following exception:
>> > Exception Details: System.Security.SecurityException: Requested
>> > registry
>> > access is not allowed.
>> >
>> > Any ideas?
>> >
>> >
>> >

"chuck rudolph" wrote:

> In the page_load, I have the following code:
> PermissionSet ps = new PermissionSet(PermissionState.None);
> ps.AddPermission(new EventLogPermission
> EventLogPermissionAccess.Instrument,"."));
> ps.Demand();
> EventLogPermission ps2 = (EventLogPermission)
> ps.GetPermission(typeof(EventLogPermission));
>
> foreach (EventLogPermissionEntry psx in ps2.PermissionEntries)
> {
>     this.Response.Write("<p> Machine: " +
>     psx.MachineName + " Bits: " + psx.PermissionAccess + " </p>");
> }
>
> When executed it writes:
> Machine: . Bits: Instrument
>
> Which would lead me to believe that I can write to an event log. But when I
> then try to execute these two lines of code:
>
> EventLog el = new EventLog("My Log",".","Login Category");
> el.WriteEntry("Login is getting ready to run!");
>
> ASP.Net (Microsoft .NET Framework Version:1.1.4322.2032) throws the
> following exception:
> Exception Details: System.Security.SecurityException: Requested registry
> access is not allowed.
>
> Any ideas?
>
>
>

"Karlo Swart" wrote:

> Hi. I have been reading this thread and I have  the same problem.
>
> I create the event log and source using an admin account and have no problem
> doing this. I now try to throw an exception (I use the Exceptionmanager
> assembly provided by MS) and use this to write to a custom event log. No
> problem in Windows 2000 from any user.
>
> On Win 2003, I can only write to the custom event log using the admin
> account. I've located the registery setting for the event log and source and
> given full permission to a user other than the systems admin. It fails again.
>  I am using integrated windows authenticaiton in IIS and windows
> authentication and identity  impersonation in my web.config.
>
> Can't see how MS has not released anything to solve the problem on Win 2003.
>
> thanks
>
> Karlo Swart
>
>
>
>
>
>
>