[syslog-ng] Bug report: syslog-ng requests too many capabilities

[Scheidler, Balázs]

Also, you can tell it not to manage capabilities with the --no-caps command
line option.

-- 
Bazsi

On Wed, Apr 18, 2018 at 3:18 PM, Gergely Nagy <algernon at balabit.com> wrote:

> Hi!
>
> >>>>> "Russenberger" == Russenberger Dominik <dominik.russenberger@
> terreactive.ch> writes:
>
>     Russenberger> Hi List,
>     Russenberger> I recently noticed something very strange: although I
> run syslog-ng as
>     Russenberger> an unprivileged user (with -u log -g log), newly created
> logfiles were
>     Russenberger> owned by root. syslog-ng shows up running as user log in
> ps, as expected.
>
>     Russenberger> In my opinion, there are 2 bugs in syslog-ng:
>     Russenberger> * if I tell a daemon to run as unprivileged user I do
> not expect it to
>     Russenberger> write files as user root. What syslog-ng is doing
> basically is faking
>     Russenberger> being an unprivileged user, while retaining capabilities
> which are
>     Russenberger> equivalent to full root permissions.
>     Russenberger> Syslog-ng should imho either run as root, with
> capabilities;
>     Russenberger> OR as unprivileged user without capabilities (except
> those
>     Russenberger> explicitly given in --caps)
>     Russenberger> * syslog-ng drops to the capabilities it gets told in
> --caps,
>     Russenberger> but later g_process_cap_modify() ignores what was
> specified.
>
> While I agree about your conclusion that syslog-ng should not use more
> capabilities than it is told - or what it needs to -, I'd like to shed
> some light on why it tries to raise its capabilities despite you telling
> it to run with less.
>
> The reason is actually pretty simple: syslog-ng supports the `owner()`
> and `group()` options for some destinations, so that it can create
> output files as a different user than syslog-ng is running under. For
> this reason, whenever creating such files, it first tries to raise its
> capabilities, just to make sure it can create them. We currently do not
> keep track of whether this is required or not, we try to raise anyway.
>
> We should probably change that, and only raise capabilities if we really
> need to. This should solve the issue you are seeing.
>
> --
> |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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.balabit.hu/pipermail/syslog-ng/attachments/20180418/3a310b59/attachment.html>