This is the sort of thing I was talking about a few weeks ago when I was
proposing having a 'trusted' subtree.
These fields are probably not the only ones that we will end up wanting to
have the logging software be the only software that fills them. Flagging
each individual field for special treatment is going to be more pain over
time than tagging a subtree (each new field that needs to be protected
will require updates to all logging software to prevent users from setting
it vs not existing until the logging software is updated to produce it)
I can easily see where you would want to know if an application logs these
things.
In addition, these fields are all ones that an application may be logging
today, but not referring to itself (the pid could be of a process it
spawns, uid/gid could be referring to a user that is logging in, etc)
David Lang
On Mon, 8 Oct 2012, William Heinbockel wrote:
Mirek,
I am on board with that opinion.
I view fields such as pid, uid, and gid to be platform specific and
should be filled out by the logger. Applications should only report the
application-specific information.
Now, a more interesting question: what should happen if the application
(incorrectly) attempts to fill out value the log implementation is
responsible for?
While this might be an implementation dependent decision, I believe the
recommendation should be that the log implementation either drops or
renames the application's value in preference of its own.
On Mon, 2012-10-08 at 13:50 -0400, Miloslav Trmac wrote:
> Hello,
> when discussing a lumberjack-enabling patch set, it was pointed out that [ugp]id
fields should be filled based on SCM_RIGHTS - and the Fedora configuration we are
considering actually does that.
>
> Both rsyslog's imuxsock and libumberlog add the following fields:
> * pid
> * uid
> * gid
> (and each adds some other fields that the other does not).
>
> Is there a consensus to mark these three as "to be filled by log implementation,
not by applications? If so, I'll go ahead and edit the wiki.
>
> Thank you,
> Mirek
> _______________________________________________
> lumberjack-developers mailing list
> lumberjack-developers(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/mailman/listinfo/lumberjack-developers
_______________________________________________
lumberjack-developers mailing list
lumberjack-developers(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/lumberjack-developers