Re: CAP_SYSLOG, 2.6.38 and user space

[Gergely Nagy <algernon@balabit.hu>]

> what's wrong with doing a runtime test at startup that tries to read with 
> CAP_SYS_ADMIN and if you get -EPERM trying again with CAP_SYSLOG?

That's also an option I considered, and might end up doing if there's no
easier option.  In my case, though, due to the design of the code, it's
not trivially simple to do that (it isn't particularly hard, either, but
such a test wouldn't be my first choice).

> creating an ioctl for something like this seems like it's significantly 
> overcomplicating the issue.

True.

Nevertheless, like I said before: my main concern is making sure
userspace doesn't break. Figuring out how to support CAP_SYSLOG best is
a much lower priority on my list, and I haven't given it all that much
thought.

I'd prefer an ioctl or something similar which I can easily query,
without having to resort to trial and error or version sniffing. But I
understand that's not the best option from a kernel PoV, so falling back
to trying to read at startup is an acceptable solution aswell.

So, yeah... I suppose simply introducing CAP_SYSLOG, and keeping
CAP_SYS_ADMIN as it is would work just fine.

-- 
|8]