Re: CAP_SYSLOG, 2.6.38 and user space

[Serge E. Hallyn]

Quoting Gergely Nagy (algernon@xxxxxxxxxx):
> Hi!
> 
> Back in november, a patch was merged into the kernel (in  commit
> ce6ada35bdf710d16582cc4869c26722547e6f11), that splits CAP_SYSLOG out of
> CAP_SYS_ADMIN.
> 
> Sadly, this has an unwelcomed consequence, that any userspace syslogd
> that formerly used CAP_SYS_ADMIN will stop working, unless upgraded, or
> otherwise adapted to the change.
> 
> However, updating userspace isn't that easy, either, if one wants to
> support multiple kernels with the same userspace binary: pre-2.6.38, one
> needs CAP_SYS_ADMIN, but later kernels will need CAP_SYS_ADMIN. It would
> be trivial to keep both, but that kind of defeats the purpose of
> CAP_SYSLOG,

The idea would be to only use both when you detect a possibly older
kernel. 

> in my opinion. It can be made configurable, and one can let
> the admin set which one to use, but that's ugly, and doesn't fix the
> underlying issue, just delegates it to the admins. And automatically
> deciding runtime proved to be trickier than I would've liked.
> 
> My question would be, and this is why I'm CCing the author & committer:
> how are userspace syslogds supposed to handle this situation?
> 
> Preferably in a way that does not need manual intervention whenever one
> changes kernel.

It had been considered to just warn in syslog, but I was (and still am)
quite sure that would have been completely ignored by userspace.

However, you're right of course, I really should have provided some way
for userspace to click 'ok, got the message, now continue anyway because
I'm running older userspace for now,'  i.e. a sysctl perhaps.

Sorry about the trouble.  Here is a patch to just warn for now, with
the changelog showing what i intend to push next.

sorry again,
-serge