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

[Balazs Scheidler]

Ok, thanks.
On Dec 12, 2013 2:23 PM, "Evan Rempel" <erempel at uvic.ca> wrote:

>  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> 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
>>
>>
>>
>
> ______________________________________________________________________________
> 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/20131214/906c447f/attachment.htm