[syslog-ng] [RFC]: syslog-ng and UNIX credentials

[Evan Rempel]

I have seen this before but it was a few years back and it was only one application using it for an instance name something like a database cluster name which made it always the same for the life of the install. That didn't make it very useful.

I haven't seen this in at least 4 years and if the "other guys" are moving in this direction and because it already is a defacto standard to use it for the PID then I am happy with that.



-------- Original message --------
From: Balazs Scheidler
Date:12/12/2013 12:36 AM (GMT-06:00)
To: Syslog-ng users' and developers' mailing list
Subject: Re: [syslog-ng] [RFC]: syslog-ng and UNIX credentials


Hi,

Thanks for the response.

Well, thats right. I was thinking on having this enabled only on /dev/log automatically via the system driver. But even there could be disabled by using the lower level drivers directly.

I havent seen anything that would use that field for something else. Did you?

Also, journal/rsyslog is doing the same.

On Dec 11, 2013 1:56 PM, "Evan Rempel" <erempel at uvic.ca<mailto:erempel at uvic.ca>> wrote:
If the PID is replaced by this new feature then the PID included in the message would be lost and according to the syslog RFC the item in [] is a unique identifier and NOT always a PID. I think that the PID included in the message should be retained, perhaps in another macro such as EPID for effective PID or something that matches the RFC description.


Sent from Samsung Mobile


-------- Original message --------
From: Gergely Nagy
Date:12/10/2013 9:16 AM (GMT-06:00)
To: syslog-ng OSE list
Subject: [syslog-ng] [RFC]: syslog-ng and UNIX credentials

Hi!

We had a short chat with Bazsi earlier today, and he's working on a
feature that will allow syslog-ng to pick out UNIX credentials passed
through unix sockets (such as /dev/log). This means that we receive the
PID, the UID and the GID of the sending program, and can opt to store it
someplace. So far, syslog-ng was not doing that, but with the new
feature, it becomes possible to store these.

The idea at the moment is, is to have a flag for unix-* sources that
enables collecting these credentials. If turned off (the default, unless
using system(), which would turn it on for /dev/log), nothing changes.
If turned on, it would replace the $PID sent over the socket with the
one extracted from credentials. It would also add the "${.unix.GID}" and
"${.unix.UID}" properties to the log message, along with "${.unix.EXE}"
on platforms that support looking up the executable (Linux, for now).

We'd like to invite the broader community to share your feelings about
this feature, the naming of the properties and how You would like it to
work, if you're interested in making use of this functionality.

--
|8]

______________________________________________________________________________
Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng
Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng
FAQ: http://www.balabit.com/wiki/syslog-ng-faq


______________________________________________________________________________
Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng
Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng
FAQ: http://www.balabit.com/wiki/syslog-ng-faq


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.balabit.hu/pipermail/syslog-ng/attachments/20131212/3f20316b/attachment.htm