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

[Gergely Nagy]

Hi!

>>>>> "Russenberger" == Russenberger Dominik <dominik.russenberger at 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]