linux-kernel - CAP_SYSLOG, 2.6.38 and user space

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 03 Feb 2011 12:39:37 +0100
From:	Gergely Nagy <algernon@...abit.hu>
To:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Cc:	"Serge E. Hallyn" <serge@...lyn.com>,
	James Morris <jmorris@...ei.org>
Subject: CAP_SYSLOG, 2.6.38 and user space

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]

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/