On 10/08/2012 05:15 PM, david(a)lang.hm wrote:
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
Then may be the fields that are generated by the interface should have a
prefix that by convention is not used for other fields. For example
instead of: pid - resolved_pid or something like. And IMO attempt to
explicitly overwrite such field in the call should return an error right
away.
If the prefix is unique there is a very low chance that the resolved
fields would be overwritten unintentionally.
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
_______________________________________________
lumberjack-developers mailing list
lumberjack-developers(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/lumberjack-developers
--
Thank you,
Dmitri Pal
Sr. Engineering Manager for IdM portfolio
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/