CAP_SYSLOG, 2.6.38 and user space

[Gergely Nagy <algernon@balabit.hu>]

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, 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.

-- 
|8]