Comment 29 for bug 407862

I think we get into the realms of Unix philosophy at this point.

What actually needs to be fixed is the ability to set permissions on
network ports and other 'root only' system facilities. Then rsyslog
could be started as a non-privileged user and still get the facilities
it requires.

This 'obtain what you require and then drop privileges' is a nasty workaround.

To be honest I prefer the Debian workaround where a root only process
grabs the relevant data and resurfaces it via a named pipe - with the
appropriate access permissions. Perhaps rsyslog should look at
adopting that approach for access to 'root-only' facilities. It
certainly prevents security holes.

2009/9/11 Rainer Gerhards <email address hidden>:
> I have integrated the patch (actually the idea as the code has evolved
> in the mean time). Thanks for the suggestions. Please note that I think
> this patch tries to fix something outside of the scope of rsyslogd. I
> have posted full details in the rsyslog's bug tracker [1] as well as in
> the doc for the new directive [2]. Consequently, this has been changed
> to a "feature request" from rsyslog's POV. As such, the "patch" goes
> into the recent devel (4.7.0). It is rsyslog policy never to add new
> features to stable or beta versions.
>
> I would appreciate discussion on my view that the root cause is outside
> of rsyslog. Discussion is especially important as I expect that the
> work-around we now created will no longer work once rsyslog has new,
> better privilege drop code (probably in the v5 or v6 timeframe).
>
> Thanks,
> Rainer
>
> [1] http://bugzilla.adiscon.com/show_bug.cgi?id=150
> [2] http://www.rsyslog.com/doc-rsconf1_omfileforcechown.html
>
> --
> [karmic] Messages not being sent to system logs
> https://bugs.launchpad.net/bugs/407862
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Neil Wilson