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

[Matthew Hall]

On Wed, Jan 19, 2011 at 06:57:15PM +0100, Gergely Nagy wrote:
> On Wed, 2011-01-19 at 09:35 -0800, Matthew Hall wrote:
> > On Wed, Jan 19, 2011 at 06:17:40PM +0100, bugzilla at bugzilla.balabit.com wrote:
> > > --- Comment #1 from Arkadiusz Miśkiewicz <arekm at maven.pl>  2011-01-19 18:17:40 ---
> > > Solution used in PLD/Linux:
> > > http://cvs.pld-linux.org/cgi-bin/cvsweb/packages/syslog-ng/cap_syslog.patch
> > 
> > +	sscanf(uts.release, "%d.%d.%d", &x, &y, &z);
> > +	kernel_version = LINUX_VERSION(x, y, z);
> > 
> > That patch is not resilient in format changes in the string.
> > 
> > If I take stuff out or add weird stuff then *.scanf functions will corrupt the stack.
> > 
> > It would be better to use a regex with capture groups and check for the right count of them, then pass that to the version macro.
> 
> I'd suggest another approach (though, I've yet to figure out if it is
> possible): try to detect whether CAP_SYSLOG is supported, and use it
> over CAP_SYS_ADMIN if it is, then fall back to CAP_SYS_ADMIN.
> 
> This would have the advantage of not requiring kernel version sniffing,
> which can be misleading.
> 
> My guess would be that if cap_set_proc() fails with CAP_SYSLOG set, then
> we can fall back to CAP_SYS_ADMIN. But like I said, this is unverified,
> untested, and so on.
> 
> I just don't trust version sniffing in any shape or form.

Good point indeed.

I didn't think about what happens when people like RH, Debian, or Ubuntu backport things.

Better just to try it, and set errno.

However what happens if the user space headers on a box are missing the CAP_SYSLOG macro but the kernel has a backport to support CAP_SYSLOG?

Matthew.