|
Boost : |
Subject: Re: [boost] [log] Review-ready version in the Vault
From: Edouard A. (edouard_at_[hidden])
Date: 2009-02-13 16:50:21
> Not sure what exactly you mean, but no, I don't think so. Event
> categories are defined in the .mc file and they are compiled into a
> binary resource, which is then utilized by the Event Viewer. This
> resource cannot be modified, other than by recompiling it.
In the call to RegisterEventSource, you specify a source. My question is how
do you handle non existing source? Do you create it? Do you let the default
behavior occur (log to application)? Do you throw an exception?
To create an event source you need to create a key in the registry and then
set appropriate rights to make sure that it cannot be modified by
unauthorized users/processes.
There is a potential security issue here. If an external process creates the
source before you do it, it will get all rights and possibly will remove
entries (or add ones, but generally you want to remove/modify entries) as it
may see fit. Sometimes the malicious application purpose is only log
duplication.
Therefore, you need to have clear behavior when creating the log source so
that when you use the sink you know what to expect. What you can do is have
a different call to create the source and throw an exception when the source
doesn't exist.
One may note that this security issue is not specific to the event viewer,
that's also true when logging to files.
> If events that are emitted by the sink contain some non-existent
> category, I guess, the Event Viewer will show them as errors. The event
> description will still be visible, though.
>
> > Can I log to a different computer than localhost?
>
> No, not yet. That can be easily added, if I'm not missing anything.
That's very interesting for distributed computing where centralizing logging
makes a lot of sense.
It's very straightforward, you just have to specify the name of the server
(UNC format) in the call to RegisterEventSource.
Kind regards.
-- Edouard Alligand
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk