Windows Service - Event Log

[Willy Denoyette [MVP]]

| > Right, but Tim has split the thread and talked about writing to the
Registry
| > (HKLM) and I replied to him not to You, right?.
|
| No, i said that in order to write to the eventlog, you need to have
| permissions to do so.


Per default, all users have the write privileges to the Application log or
any other private log, only administrator have the write privs. to the
System log, and no-one can directly write to the Security log.
But this is not the point, You said...

If i remember well, i had to give the
| 'network' user access rights to the registry keys..
|
I asked..

What registry key's?

and you replied with:
HKLM/System/CurrentControlSet/Services/Eventlog (or one of it's
children).

and I answered with:

Yes, but why do you want your service to write to this key?
Only Administrators (and localsystem) are allowed to write to HKLM and
descendants, Service accounts are not supposed to write to HKLM. If you
really need your service to write to HKLM, you need to run as "localsystem".
Again if you grant a non privileged account write access to HKLM, you
severely compromise your system's security.

And the point is that giving network user (I guess you mean "Network
Service) write access privileges to
HKLM/System/CurrentControlSet/Services/Eventlog is only required if you want
"Network service" to create the 'source' (private log), which is bad
practice.
Let an administrator create the source (remember "Network Service" is a
restricted account, don't give hime more rights than he deserves and
"Network service" will automatically be able to write to this log without
granting any elevated privileges.


Willy.

 

[Kevin Spencer]

Who's talking about writing to the eventlog? Tim and I are talking about
You (Tim and you, as you prefer to put it, although I could almost swear
that I am too) are talking about creating an Event Log, and writing to it.
Yes, this is done via the System registry, but the registry does not have a
single set of permissions for all registry keys. It has highly granular
permissions. If writing a .Net application, you are not likely to be writing
directly to the registry in order to do this, but more likely to be using
the EventLog classes.

To create an Event Log, the user account must be a member of the
Administrators group on the local machine, or the local System account. The
permissions can be changed as well, but that is not likely to be helpful
(as, when the application moves to a different machine, the permissions must
be changed on any machine it is moved to). So, what I said still stands: If
you want your service to create an Event Log, it must run as a user account
that is either the Local System or a member of the Administrators group. If
you have a look at your Service Manager, you will see that many Services run
under these types of accounts, and for a variety of reasons.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Chicken Salad Alchemist

Big thicks are made up of lots of little thins.

 

[Willy Denoyette [MVP]]

| >> Who's talking about writing to the eventlog? Tim and I are talking
about
| >> writing to the registry ( HKLM ).
|
| You (Tim and you, as you prefer to put it, although I could almost swear
| that I am too)


No, I was only talking about writing to the Registry (more exactly to HKLM)
again re-read my response to Tim.
You (and Tim as I found out later) are talking about writing to the Registry
for the purpose of creating a log entry.

| Yes, this is done via the System registry, but the registry does not have
a
| single set of permissions for all registry keys. It has highly granular
| permissions. If writing a .Net application, you are not likely to be
writing
| directly to the registry in order to do this, but more likely to be using
| the EventLog classes.
|

That's what I tried to explain to Tim - user applications and user services
for that matter, better stay away from the registry security settings
especially from HKLM, right?

| To create an Event Log, the user account must be a member of the
| Administrators group on the local machine, or the local System account.

That's right, but that doesn't mean it's the task of the service to create
the log, you don't want your service to run as localsystem (or worse as
administrator), just for the purpose of a one time creation of a log entry
(source) do you? This is the task of a separate administrative tool, a
simple five lines C# application or a simple vbscript, that should be run as
part of the service deployement.

The
| permissions can be changed as well, but that is not likely to be helpful
| (as, when the application moves to a different machine, the permissions
must
| be changed on any machine it is moved to). So, what I said still stands:
If
| you want your service to create an Event Log, it must run as a user
account
| that is either the Local System or a member of the Administrators group.
If
| you have a look at your Service Manager, you will see that many Services
run
| under these types of accounts, and for a variety of reasons.
|

None of the services run as Administrator, a great deal run as SYSTEM (on
anything except Vista and LH server) but this will soon be history, MSFT has
learned a lesson. A number of servives still run as localsystem, just
because they can't/won't change that to a less privileged user without
changing other depending processes as well, those that could be changed
easely are now running as Local Service or Network Service.
The major reason (bute there are others) for this is a design flaw in the
"LogonUser" API which requires TCB privileges on anything below XP and W2K3.
TCB privileges are only granted to 'localsystem' on NT4 and W2K, that means
that Services that need to impersonate must run as SYSTEM on these downlevel
OS'ses. Again these services are the number one security attack targets, and
it's not because MSFT made a mistake that you should follow their example
right?

Willy.

 

[Kevin Spencer]

Just one comment:

None of the services run as Administrator, a great deal run as SYSTEM (on

I didn't say the Administrator account. I said "a member of the
Administrators group on the local machine."

That said, I didn't advocate using a member of the Administrator's group; it
was just information.

As to whether or not a Service should run as the Local System account,
that's a matter of what the Service does (requirements). Whether it should
be run as Local System just to create an Event Log, that isn't necessary, as
the installation could set up the Event Log. Of course, the person running
the installation would have to be a member of the Administrator's group to
do this.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Chicken Salad Alchemist

Big thicks are made up of lots of little thins.

 

[Willy Denoyette [MVP]]

| Just one comment:
|
| > None of the services run as Administrator, a great deal run as SYSTEM
(on
|
| I didn't say the Administrator account. I said "a member of the
| Administrators group on the local machine."
|
Nor did I, an Administrator IS a member of the administrators group, I
didn't spell THE Administrator, right? But if you insist, none of my
services run as 'a member of the Administrators group".


| That said, I didn't advocate using a member of the Administrator's group;
it
| was just information.
|
| As to whether or not a Service should run as the Local System account,
| that's a matter of what the Service does (requirements). Whether it should
| be run as Local System just to create an Event Log, that isn't necessary,
as
| the installation could set up the Event Log. Of course, the person running
| the installation would have to be a member of the Administrator's group to
| do this.

Sure, but that's the role of an admin, execute tasks that require
administrative privileges. The problem with the framework however is, that
none of the API's are documenting these security requirements.

Consider the sample in the docs:
// Create the source, if it does not already exist.
if(!EventLog.SourceExists("MySource")){
EventLog.CreateEventSource("MySource", "MyNewLog");
Console.WriteLine("CreatingEventSource");

....

This should be run by an "administrator", for two reasons:
1. The CreateEventSource call, creates the key MySource in
HKLM/System/CurrentControlSet/Services/Eventlog
2. and CreateEventSource creates the logfile in %windir%\system32\config
which only allows admins to create files into.

Someone running this code as non-admin, will encounter two security issues
and will start tweaking the registry and the filesystem, bummer. More, he
will probably post this as THE solution for the issue at hand.

Willy.

 

[krisXp Xp]

It has got nothing to do with Event log and permissions.
Check your Onstart Method. Have a timer on your service design page and
have timer1.Enabled = true in your start method and
write every thing else in timer1.elapsed event.

 

[Pierre Cornelissen]

I get most of my info from the Internet, but sometimes I have to revert
to good old faithful MSDN, which in itself is sometimes a nightmare to
find relevant solutions. Sometimes I need to take a shower and really
start thinking. The following solution I cannot guarantee, but in .NET
developed applications, where you have a lot of memory and high speed
processors, especially dual processors and that includes hyper threaded
processors, this just may help solving the problem.

The Garbage Collector plays a big role in this. If you opens the tread,
instantiate an object and does not use that object fast enough, it just
may end up in the GC purse. So turn off the aggressive garbage
collection by the following statement:

//C# Code
CG.KeepAlive(myObject);

I have a service using System.Timers namespace. Yesterday everything
was working fine, all of a sudden my PC restarted while the timer
service was running, and I could not get the service up and running,
until the line of code above.

As I said it may not work in all instances, especially I cannot help
those calling of-the-shelve applications.

Hope this will help.

Pierre

 

[SenthilKumar Arunachalam]

I hope you added the local webreference in the windows Service.

Simply you change service process installer Account into LocalSystem.