Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756304Ab1BCLjm (ORCPT ); Thu, 3 Feb 2011 06:39:42 -0500 Received: from brother.balabit.com ([195.70.62.219]:60848 "EHLO lists.balabit.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756245Ab1BCLjl (ORCPT ); Thu, 3 Feb 2011 06:39:41 -0500 Subject: CAP_SYSLOG, 2.6.38 and user space From: Gergely Nagy To: Linux Kernel Mailing List Cc: "Serge E. Hallyn" , James Morris Content-Type: text/plain; charset="UTF-8" Date: Thu, 03 Feb 2011 12:39:37 +0100 Message-ID: <1296733177.14846.26.camel@moria> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1367 Lines: 34 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/