[lkml]   [2011]   [Feb]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectCAP_SYSLOG, 2.6.38 and user space

Back in november, a patch was merged into the kernel (in commit
ce6ada35bdf710d16582cc4869c26722547e6f11), that splits CAP_SYSLOG out of

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.


 \ /
  Last update: 2011-02-03 12:41    [W:0.078 / U:11.656 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site