[syslog-ng] [Bug 108] 2.6.38+ will require CAP_SYSLOG (CAP_SYS_ADMIN not enough)

[Gergely Nagy]

On Thu, 2011-01-20 at 09:26 -0800, Matthew Hall wrote:
> On Thu, Jan 20, 2011 at 06:16:16PM +0100, bugzilla at bugzilla.balabit.com wrote:
> > --- Comment #7 from Gergely Nagy <algernon at balabit.hu>  2011-01-20 18:16:16 ---
> > Did some more research, and this is looking to be harder and harder 
> > without some kind of version sniffing.
> > 
> > Using a libcap that doesn't know a thing about CAP_SYSLOG, syslog-ng 
> > will abort on 'cap_syslog=ep' on startup, regardless of what kernel is 
> > running under it (tested with stock Debian Squeeze kernel, 
> > 2.6.32+patches, no CAP_SYSLOG; and with 2.6.38-rc1 with CAP_SYSLOG). 
> > Using a patched libcap that does know about CAP_SYSLOG will succeed, 
> > on both kernels, and even if I try to verify that the process has the 
> > flag I just set, it still returns true for both kernels, regardless 
> > whether they do support CAP_SYSLOG or not.
> > 
> > This looks rather hopeless to me, unfortunately.
> 
> You didn't clarify the cause of the abort. Perhaps something could be 
> done to prevent the abort from occurring? If not I suppose you are 
> hosed.

The abort can be worked around (though it wouldn't be trivial) and
retried without cap_syslog, but that wouldn't solve anything: a patched
libcap would still happily set it on kernels that don't support it. Even
if an unpatched libcap would set it on 2.6.38, the best we could do this
way is to set both.

And that would be rather pointless, as the whole idea of CAP_SYSLOG is
to replace CAP_SYS_ADMIN for this purpose.

> Regarding the success in the patched library, you could figure out it 
> didn't work by getting back an error when you open the syslog device, 
> and then try again with the admin capability set, no?

That's one of the options I'm exploring. I'm not quite sure, though, if
I'd be able to set CAP_SYSLOG at that point.

-- 
|8]