* CAP_SYSLOG, 2.6.38 and user space @ 2011-02-03 11:39 Gergely Nagy 2011-02-03 15:13 ` Alan Cox 2011-02-03 15:32 ` Serge E. Hallyn 0 siblings, 2 replies; 27+ messages in thread From: Gergely Nagy @ 2011-02-03 11:39 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Serge E. Hallyn, James Morris 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] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: CAP_SYSLOG, 2.6.38 and user space 2011-02-03 11:39 CAP_SYSLOG, 2.6.38 and user space Gergely Nagy @ 2011-02-03 15:13 ` Alan Cox 2011-02-03 15:32 ` Serge E. Hallyn 1 sibling, 0 replies; 27+ messages in thread From: Alan Cox @ 2011-02-03 15:13 UTC (permalink / raw) To: Gergely Nagy; +Cc: Linux Kernel Mailing List, Serge E. Hallyn, James Morris On Thu, 03 Feb 2011 12:39:37 +0100 Gergely Nagy <algernon@balabit.hu> wrote: > 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. Then the patch should probably be reverted as it's breaking an existing userspace API (or the kernel should accept either SYSLOG || ADMIN in those cases that check is made so that the old right covers it as well as the split out one) Alan ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: CAP_SYSLOG, 2.6.38 and user space 2011-02-03 11:39 CAP_SYSLOG, 2.6.38 and user space Gergely Nagy 2011-02-03 15:13 ` Alan Cox @ 2011-02-03 15:32 ` Serge E. Hallyn 2011-02-03 15:53 ` Gergely Nagy ` (2 more replies) 1 sibling, 3 replies; 27+ messages in thread From: Serge E. Hallyn @ 2011-02-03 15:32 UTC (permalink / raw) To: Gergely Nagy; +Cc: Linux Kernel Mailing List, Serge E. Hallyn, James Morris Quoting 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, 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 >From 2d7408541dd3a6e19a4265b028233789be6a40f4 Mon Sep 17 00:00:00 2001 From: Serge Hallyn <serge@peq.(none)> Date: Thu, 3 Feb 2011 09:26:15 -0600 Subject: [PATCH 1/1] cap_syslog: don't refuse cap_sys_admin for now At 2.6.39 or 2.6.40, let's add a sysctl which defaults to 0. When 0, refuse if cap_sys_admin, if 1, then allow. This will allow users to acknowledge (permanently, if they must, using /etc/sysctl.conf) that they've seen the syslog message about cap_sys_admin being deprecated for syslog. Signed-off-by: Serge Hallyn <serge@hallyn.com> --- kernel/printk.c | 26 ++++++++++++++++---------- 1 files changed, 16 insertions(+), 10 deletions(-) diff --git a/kernel/printk.c b/kernel/printk.c index 2ddbdc7..bc56386 100644 --- a/kernel/printk.c +++ b/kernel/printk.c @@ -274,12 +274,24 @@ int do_syslog(int type, char __user *buf, int len, bool from_file) * at open time. */ if (type == SYSLOG_ACTION_OPEN || !from_file) { - if (dmesg_restrict && !capable(CAP_SYSLOG)) - goto warn; /* switch to return -EPERM after 2.6.39 */ + if (dmesg_restrict && !capable(CAP_SYSLOG)) { + /* remove after 2.6.39 */ + if (capable(CAP_SYS_ADMIN)) + WARN_ONCE(1, "Attempt to access syslog with CAP_SYS_ADMIN " + "but no CAP_SYSLOG (deprecated).\n"); + else + return -EPERM; + } if ((type != SYSLOG_ACTION_READ_ALL && type != SYSLOG_ACTION_SIZE_BUFFER) && - !capable(CAP_SYSLOG)) - goto warn; /* switch to return -EPERM after 2.6.39 */ + !capable(CAP_SYSLOG)) { + /* remove after 2.6.39 */ + if (capable(CAP_SYS_ADMIN)) + WARN_ONCE(1, "Attempt to access syslog with CAP_SYS_ADMIN " + "but no CAP_SYSLOG (deprecated).\n"); + else + return -EPERM; + } } error = security_syslog(type); @@ -423,12 +435,6 @@ int do_syslog(int type, char __user *buf, int len, bool from_file) } out: return error; -warn: - /* remove after 2.6.39 */ - if (capable(CAP_SYS_ADMIN)) - WARN_ONCE(1, "Attempt to access syslog with CAP_SYS_ADMIN " - "but no CAP_SYSLOG (deprecated and denied).\n"); - return -EPERM; } SYSCALL_DEFINE3(syslog, int, type, char __user *, buf, int, len) -- 1.7.2.3 ^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: CAP_SYSLOG, 2.6.38 and user space 2011-02-03 15:32 ` Serge E. Hallyn @ 2011-02-03 15:53 ` Gergely Nagy 2011-02-03 16:51 ` Serge E. Hallyn 2011-02-03 15:54 ` Nick Bowler 2011-02-04 16:05 ` Serge E. Hallyn 2 siblings, 1 reply; 27+ messages in thread From: Gergely Nagy @ 2011-02-03 15:53 UTC (permalink / raw) To: Serge E. Hallyn; +Cc: Linux Kernel Mailing List, James Morris On Thu, 2011-02-03 at 15:32 +0000, Serge E. Hallyn wrote: > > 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. I was considering that, but... how do I reliably detect an older kernel? So far, I didn't find a reliable way with which I can detect a kernel version at run-time (apart from parsing utsname) - but it's entirely possible, that I missed something obvious. Furthermore, this still needs an userspace upgrade aswell, so only helps one half of the problem. > 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 > > From 2d7408541dd3a6e19a4265b028233789be6a40f4 Mon Sep 17 00:00:00 2001 > From: Serge Hallyn <serge@peq.(none)> > Date: Thu, 3 Feb 2011 09:26:15 -0600 > Subject: [PATCH 1/1] cap_syslog: don't refuse cap_sys_admin for now > > At 2.6.39 or 2.6.40, let's add a sysctl which defaults to 0. When > 0, refuse if cap_sys_admin, if 1, then allow. This will allow > users to acknowledge (permanently, if they must, using /etc/sysctl.conf) > that they've seen the syslog message about cap_sys_admin being > deprecated for syslog. Could we have it the other way around, at least for a while? Otherwise, if someone happens to upgrade the kernel, and forgets to upgrade the syslogd, he'll still experience breakage. With defaulting to 1, compatiblity is kept, and systems that were upgraded properly can set it to 0 and live happily ever after. The WARNs should prompt people to upgrade at the first opportunity, so hopefully, it won't go unnoticed and ignored by userspace. I'm not sure one would even see the kernel warn with the syslogd not being able to read the kernel messages (dmesg, of course, would reveal it, but that's one extra step). -- |8] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: CAP_SYSLOG, 2.6.38 and user space 2011-02-03 15:53 ` Gergely Nagy @ 2011-02-03 16:51 ` Serge E. Hallyn 2011-02-03 17:07 ` Gergely Nagy 2011-02-04 0:49 ` david 0 siblings, 2 replies; 27+ messages in thread From: Serge E. Hallyn @ 2011-02-03 16:51 UTC (permalink / raw) To: Gergely Nagy; +Cc: Serge E. Hallyn, Linux Kernel Mailing List, James Morris Quoting Gergely Nagy (algernon@balabit.hu): > On Thu, 2011-02-03 at 15:32 +0000, Serge E. Hallyn wrote: > > > 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. > > I was considering that, but... how do I reliably detect an older kernel? > So far, I didn't find a reliable way with which I can detect a kernel > version at run-time (apart from parsing utsname) ... Why not parse utsname? > - but it's entirely > possible, that I missed something obvious. > > Furthermore, this still needs an userspace upgrade aswell, so only helps > one half of the problem. True, that only addresses the less forgivable problem I introduced, namely what does updated userspace even do to do the right thing. > > 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 > > > > From 2d7408541dd3a6e19a4265b028233789be6a40f4 Mon Sep 17 00:00:00 2001 > > From: Serge Hallyn <serge@peq.(none)> > > Date: Thu, 3 Feb 2011 09:26:15 -0600 > > Subject: [PATCH 1/1] cap_syslog: don't refuse cap_sys_admin for now > > > > At 2.6.39 or 2.6.40, let's add a sysctl which defaults to 0. When > > 0, refuse if cap_sys_admin, if 1, then allow. This will allow > > users to acknowledge (permanently, if they must, using /etc/sysctl.conf) > > that they've seen the syslog message about cap_sys_admin being > > deprecated for syslog. > > Could we have it the other way around, at least for a while? Otherwise, Sure. So long as there is a definite path toward eventually having syslog with CAP_SYS_ADMIN be denied. > if someone happens to upgrade the kernel, and forgets to upgrade the > syslogd, he'll still experience breakage. With defaulting to 1, > compatiblity is kept, and systems that were upgraded properly can set it > to 0 and live happily ever after. The WARNs should prompt people to > upgrade at the first opportunity, so hopefully, it won't go unnoticed > and ignored by userspace. > > I'm not sure one would even see the kernel warn with the syslogd not > being able to read the kernel messages (dmesg, of course, would reveal > it, but that's one extra step). -serge ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: CAP_SYSLOG, 2.6.38 and user space 2011-02-03 16:51 ` Serge E. Hallyn @ 2011-02-03 17:07 ` Gergely Nagy 2011-02-04 0:49 ` david 1 sibling, 0 replies; 27+ messages in thread From: Gergely Nagy @ 2011-02-03 17:07 UTC (permalink / raw) To: Serge E. Hallyn; +Cc: Linux Kernel Mailing List, James Morris On Thu, 2011-02-03 at 16:51 +0000, Serge E. Hallyn wrote: > > > The idea would be to only use both when you detect a possibly older > > > kernel. > > > > I was considering that, but... how do I reliably detect an older kernel? > > So far, I didn't find a reliable way with which I can detect a kernel > > version at run-time (apart from parsing utsname) > > ... Why not parse utsname? It looks like an ugly hack to me. Apart from that, I can't list anything against it. On the other hand, the sysctl is a much better idea, I'd say, and having that means one doesn't have to parse utsname either. > > > From 2d7408541dd3a6e19a4265b028233789be6a40f4 Mon Sep 17 00:00:00 2001 > > > From: Serge Hallyn <serge@peq.(none)> > > > Date: Thu, 3 Feb 2011 09:26:15 -0600 > > > Subject: [PATCH 1/1] cap_syslog: don't refuse cap_sys_admin for now > > > > > > At 2.6.39 or 2.6.40, let's add a sysctl which defaults to 0. When > > > 0, refuse if cap_sys_admin, if 1, then allow. This will allow > > > users to acknowledge (permanently, if they must, using /etc/sysctl.conf) > > > that they've seen the syslog message about cap_sys_admin being > > > deprecated for syslog. > > > > Could we have it the other way around, at least for a while? Otherwise, > > Sure. > > So long as there is a definite path toward eventually having syslog > with CAP_SYS_ADMIN be denied. \o/ -- |8] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: CAP_SYSLOG, 2.6.38 and user space 2011-02-03 16:51 ` Serge E. Hallyn 2011-02-03 17:07 ` Gergely Nagy @ 2011-02-04 0:49 ` david 2011-02-04 8:03 ` Marc Koschewski 2011-02-04 16:03 ` Serge E. Hallyn 1 sibling, 2 replies; 27+ messages in thread From: david @ 2011-02-04 0:49 UTC (permalink / raw) To: Serge E. Hallyn; +Cc: Gergely Nagy, Linux Kernel Mailing List, James Morris On Thu, 3 Feb 2011, Serge E. Hallyn wrote: > Quoting Gergely Nagy (algernon@balabit.hu): >> On Thu, 2011-02-03 at 15:32 +0000, Serge E. Hallyn wrote: >>>> 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. >> >> I was considering that, but... how do I reliably detect an older kernel? >> So far, I didn't find a reliable way with which I can detect a kernel >> version at run-time (apart from parsing utsname) > > ... Why not parse utsname? because the name may be different on different systems, a generic software package is not going to be able to interpret them all. >>> 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 >>> >>> From 2d7408541dd3a6e19a4265b028233789be6a40f4 Mon Sep 17 00:00:00 2001 >>> From: Serge Hallyn <serge@peq.(none)> >>> Date: Thu, 3 Feb 2011 09:26:15 -0600 >>> Subject: [PATCH 1/1] cap_syslog: don't refuse cap_sys_admin for now >>> >>> At 2.6.39 or 2.6.40, let's add a sysctl which defaults to 0. When >>> 0, refuse if cap_sys_admin, if 1, then allow. This will allow >>> users to acknowledge (permanently, if they must, using /etc/sysctl.conf) >>> that they've seen the syslog message about cap_sys_admin being >>> deprecated for syslog. >> >> Could we have it the other way around, at least for a while? Otherwise, > > Sure. > > So long as there is a definite path toward eventually having syslog > with CAP_SYS_ADMIN be denied. I can see what you would want to allow for a syslog daemon to have CAP_SYSLOG without needing to have CAP_SYS_ADMIN, but why do you see it as important to deny the ability if someone has CAP_SYS_ADMIN? David Lang ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: CAP_SYSLOG, 2.6.38 and user space 2011-02-04 0:49 ` david @ 2011-02-04 8:03 ` Marc Koschewski 2011-02-04 8:40 ` Gergely Nagy 2011-02-04 16:03 ` Serge E. Hallyn 1 sibling, 1 reply; 27+ messages in thread From: Marc Koschewski @ 2011-02-04 8:03 UTC (permalink / raw) To: david Cc: Serge E. Hallyn, Gergely Nagy, Linux Kernel Mailing List, James Morris Hey, * david@lang.hm <david@lang.hm> [2011-02-03 16:49:08 -0800]: > On Thu, 3 Feb 2011, Serge E. Hallyn wrote: > > >Quoting Gergely Nagy (algernon@balabit.hu): > >>On Thu, 2011-02-03 at 15:32 +0000, Serge E. Hallyn wrote: > >>>>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. > >> > >>I was considering that, but... how do I reliably detect an older kernel? > >>So far, I didn't find a reliable way with which I can detect a kernel > >>version at run-time (apart from parsing utsname) > > > >... Why not parse utsname? > > because the name may be different on different systems, a generic software > package is not going to be able to interpret them all. > > >>>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 > >>> > >>>From 2d7408541dd3a6e19a4265b028233789be6a40f4 Mon Sep 17 00:00:00 2001 > >>>From: Serge Hallyn <serge@peq.(none)> > >>>Date: Thu, 3 Feb 2011 09:26:15 -0600 > >>>Subject: [PATCH 1/1] cap_syslog: don't refuse cap_sys_admin for now > >>> > >>>At 2.6.39 or 2.6.40, let's add a sysctl which defaults to 0. When > >>>0, refuse if cap_sys_admin, if 1, then allow. This will allow > >>>users to acknowledge (permanently, if they must, using /etc/sysctl.conf) > >>>that they've seen the syslog message about cap_sys_admin being > >>>deprecated for syslog. > >> > >>Could we have it the other way around, at least for a while? Otherwise, > > > >Sure. > > > >So long as there is a definite path toward eventually having syslog > >with CAP_SYS_ADMIN be denied. > > I can see what you would want to allow for a syslog daemon to have > CAP_SYSLOG without needing to have CAP_SYS_ADMIN, but why do you see it as > important to deny the ability if someone has CAP_SYS_ADMIN? ack++ Moreover, this change really is 'hell' on _many_ machines. We had discussed a thousands time to not break existing applications. So a) either make it optional in the kernel so that userspace still works with CAP_SYS_ADMIN _and_ CAP_SYSLOG while dropping a note that it should be fixed in userspace _and_ mark it as deprecated as of mid 2012 or b) revert it. > > David Lang > > -- > 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/ > > -- Marc Koschewski ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: CAP_SYSLOG, 2.6.38 and user space 2011-02-04 8:03 ` Marc Koschewski @ 2011-02-04 8:40 ` Gergely Nagy 2011-02-04 11:08 ` Alan Cox 0 siblings, 1 reply; 27+ messages in thread From: Gergely Nagy @ 2011-02-04 8:40 UTC (permalink / raw) To: Marc Koschewski Cc: david, Serge E. Hallyn, Linux Kernel Mailing List, James Morris On Fri, 2011-02-04 at 09:03 +0100, Marc Koschewski wrote: > Moreover, this change really is 'hell' on _many_ machines. We had discussed a > thousands time to not break existing applications. So a) either make it optional in > the kernel so that userspace still works with CAP_SYS_ADMIN _and_ CAP_SYSLOG > while dropping a note that it should be fixed in userspace _and_ mark it as > deprecated as of mid 2012 or b) revert it. I think the sysctl method would be superior, because it places the migration time in the hands of the distributions/admins, and gives syslogds a way to adjust, and use either CAP_SYS_ADMIN or CAP_SYSLOG, based on the presence of the sysctl setting (as opposed to using either and just postponing the flag-day from 2.6.38 to mid 2012, where we'd have the same issues we have now: unupgraded userspace breaking). Having both CAP_SYS_ADMIN and CAP_SYSLOG at the same time, for the sole purpose of reading kernel log messages would kind of defeat the purpose of CAP_SYSLOG. Therefore, a solution that allows both at the same time doesn't look all that good to me. However, having it toggle-able does, and solves all my worries at least: defaulting to CAP_SYS_ADMIN maintains backwards compatibility, upgraded systems can switch to CAP_SYSLOG if and when the system is ready for that. All's well! -- |8] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: CAP_SYSLOG, 2.6.38 and user space 2011-02-04 8:40 ` Gergely Nagy @ 2011-02-04 11:08 ` Alan Cox 0 siblings, 0 replies; 27+ messages in thread From: Alan Cox @ 2011-02-04 11:08 UTC (permalink / raw) To: Gergely Nagy Cc: Marc Koschewski, david, Serge E. Hallyn, Linux Kernel Mailing List, James Morris > Having both CAP_SYS_ADMIN and CAP_SYSLOG at the same time, for the sole > purpose of reading kernel log messages would kind of defeat the purpose > of CAP_SYSLOG. Therefore, a solution that allows both at the same time > doesn't look all that good to me. If you do it right you don't need both, you need either, so old code will use CAP_SYS_ADMIN and work, newer code will use CAP_SYSLOG and work but hold less rights. In a couple of years you can then drop the CAP_SYS_ADMIN ability to read log files, providing it is in the list of API deprecations soon... > However, having it toggle-able does, and solves all my worries at least: > defaulting to CAP_SYS_ADMIN maintains backwards compatibility, upgraded > systems can switch to CAP_SYSLOG if and when the system is ready for > that. All's well! Still a mess, we don't break ABIs at random so this patch needs reverting or fixing ASAP, otherwise Linus will just revert it anyway.. Alan ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: CAP_SYSLOG, 2.6.38 and user space 2011-02-04 0:49 ` david 2011-02-04 8:03 ` Marc Koschewski @ 2011-02-04 16:03 ` Serge E. Hallyn 1 sibling, 0 replies; 27+ messages in thread From: Serge E. Hallyn @ 2011-02-04 16:03 UTC (permalink / raw) To: david Cc: Serge E. Hallyn, Gergely Nagy, Linux Kernel Mailing List, James Morris Quoting david@lang.hm (david@lang.hm): > I can see what you would want to allow for a syslog daemon to have > CAP_SYSLOG without needing to have CAP_SYS_ADMIN, but why do you see > it as important to deny the ability if someone has CAP_SYS_ADMIN? Good point, most of its use is in going the other way. -serge ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: CAP_SYSLOG, 2.6.38 and user space 2011-02-03 15:32 ` Serge E. Hallyn 2011-02-03 15:53 ` Gergely Nagy @ 2011-02-03 15:54 ` Nick Bowler 2011-02-04 16:05 ` Serge E. Hallyn 2 siblings, 0 replies; 27+ messages in thread From: Nick Bowler @ 2011-02-03 15:54 UTC (permalink / raw) To: Serge E. Hallyn; +Cc: Gergely Nagy, Linux Kernel Mailing List, James Morris On 2011-02-03 15:32 +0000, Serge E. Hallyn wrote: > At 2.6.39 or 2.6.40, let's add a sysctl which defaults to 0. When > 0, refuse if cap_sys_admin, if 1, then allow. This had better default to 1, since that's the "don't break working systems" setting. Users (more likely, distributions) can set it to 0 when they have new enough userspace. > This will allow users to acknowledge (permanently, if they must, using > /etc/sysctl.conf) that they've seen the syslog message about > cap_sys_admin being deprecated for syslog. Why should the user need to acknowledge anything in order for their system to not be broken? What are they supposed to do otherwise? -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: CAP_SYSLOG, 2.6.38 and user space 2011-02-03 15:32 ` Serge E. Hallyn 2011-02-03 15:53 ` Gergely Nagy 2011-02-03 15:54 ` Nick Bowler @ 2011-02-04 16:05 ` Serge E. Hallyn 2011-02-04 16:33 ` Gergely Nagy 2 siblings, 1 reply; 27+ messages in thread From: Serge E. Hallyn @ 2011-02-04 16:05 UTC (permalink / raw) To: James Morris; +Cc: Gergely Nagy, Linux Kernel Mailing List Quoting Serge E. Hallyn (serge@hallyn.com): > >From 2d7408541dd3a6e19a4265b028233789be6a40f4 Mon Sep 17 00:00:00 2001 > From: Serge Hallyn <serge@peq.(none)> > Date: Thu, 3 Feb 2011 09:26:15 -0600 > Subject: [PATCH 1/1] cap_syslog: don't refuse cap_sys_admin for now > > At 2.6.39 or 2.6.40, let's add a sysctl which defaults to 0. When > 0, refuse if cap_sys_admin, if 1, then allow. This will allow > users to acknowledge (permanently, if they must, using /etc/sysctl.conf) > that they've seen the syslog message about cap_sys_admin being > deprecated for syslog. > > Signed-off-by: Serge Hallyn <serge@hallyn.com> > --- > kernel/printk.c | 26 ++++++++++++++++---------- > 1 files changed, 16 insertions(+), 10 deletions(-) > > diff --git a/kernel/printk.c b/kernel/printk.c > index 2ddbdc7..bc56386 100644 > --- a/kernel/printk.c > +++ b/kernel/printk.c > @@ -274,12 +274,24 @@ int do_syslog(int type, char __user *buf, int len, bool from_file) > * at open time. > */ > if (type == SYSLOG_ACTION_OPEN || !from_file) { > - if (dmesg_restrict && !capable(CAP_SYSLOG)) > - goto warn; /* switch to return -EPERM after 2.6.39 */ > + if (dmesg_restrict && !capable(CAP_SYSLOG)) { > + /* remove after 2.6.39 */ > + if (capable(CAP_SYS_ADMIN)) > + WARN_ONCE(1, "Attempt to access syslog with CAP_SYS_ADMIN " > + "but no CAP_SYSLOG (deprecated).\n"); > + else > + return -EPERM; > + } > if ((type != SYSLOG_ACTION_READ_ALL && > type != SYSLOG_ACTION_SIZE_BUFFER) && > - !capable(CAP_SYSLOG)) > - goto warn; /* switch to return -EPERM after 2.6.39 */ > + !capable(CAP_SYSLOG)) { > + /* remove after 2.6.39 */ > + if (capable(CAP_SYS_ADMIN)) > + WARN_ONCE(1, "Attempt to access syslog with CAP_SYS_ADMIN " > + "but no CAP_SYSLOG (deprecated).\n"); > + else > + return -EPERM; > + } > } > > error = security_syslog(type); > @@ -423,12 +435,6 @@ int do_syslog(int type, char __user *buf, int len, bool from_file) > } > out: > return error; > -warn: > - /* remove after 2.6.39 */ > - if (capable(CAP_SYS_ADMIN)) > - WARN_ONCE(1, "Attempt to access syslog with CAP_SYS_ADMIN " > - "but no CAP_SYSLOG (deprecated and denied).\n"); > - return -EPERM; > } > > SYSCALL_DEFINE3(syslog, int, type, char __user *, buf, int, len) > -- > 1.7.2.3 > James, do you mind taking this patch? thanks, -serge ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: CAP_SYSLOG, 2.6.38 and user space 2011-02-04 16:05 ` Serge E. Hallyn @ 2011-02-04 16:33 ` Gergely Nagy 2011-02-04 17:15 ` Serge E. Hallyn 0 siblings, 1 reply; 27+ messages in thread From: Gergely Nagy @ 2011-02-04 16:33 UTC (permalink / raw) To: Serge E. Hallyn; +Cc: James Morris, Linux Kernel Mailing List On Fri, 2011-02-04 at 16:05 +0000, Serge E. Hallyn wrote: > Quoting Serge E. Hallyn (serge@hallyn.com): > > >From 2d7408541dd3a6e19a4265b028233789be6a40f4 Mon Sep 17 00:00:00 2001 > > From: Serge Hallyn <serge@peq.(none)> > > Date: Thu, 3 Feb 2011 09:26:15 -0600 > > Subject: [PATCH 1/1] cap_syslog: don't refuse cap_sys_admin for now > > > > At 2.6.39 or 2.6.40, let's add a sysctl which defaults to 0. When > > 0, refuse if cap_sys_admin, if 1, then allow. This will allow > > users to acknowledge (permanently, if they must, using /etc/sysctl.conf) > > that they've seen the syslog message about cap_sys_admin being > > deprecated for syslog. > > > > Signed-off-by: Serge Hallyn <serge@hallyn.com> [...snip...] > James, do you mind taking this patch? Would it be possible to change the commit message to say that 1 would be the default? Just to avoid future confusion... (having it at 0 default later would just postpone the userspace breakage) -- |8] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: CAP_SYSLOG, 2.6.38 and user space 2011-02-04 16:33 ` Gergely Nagy @ 2011-02-04 17:15 ` Serge E. Hallyn 2011-02-05 7:05 ` david 2011-02-09 19:50 ` Gergely Nagy 0 siblings, 2 replies; 27+ messages in thread From: Serge E. Hallyn @ 2011-02-04 17:15 UTC (permalink / raw) To: Gergely Nagy; +Cc: Serge E. Hallyn, James Morris, Linux Kernel Mailing List Quoting Gergely Nagy (algernon@balabit.hu): > On Fri, 2011-02-04 at 16:05 +0000, Serge E. Hallyn wrote: > > Quoting Serge E. Hallyn (serge@hallyn.com): > > > >From 2d7408541dd3a6e19a4265b028233789be6a40f4 Mon Sep 17 00:00:00 2001 > > > From: Serge Hallyn <serge@peq.(none)> > > > Date: Thu, 3 Feb 2011 09:26:15 -0600 > > > Subject: [PATCH 1/1] cap_syslog: don't refuse cap_sys_admin for now > > > > > > At 2.6.39 or 2.6.40, let's add a sysctl which defaults to 0. When > > > 0, refuse if cap_sys_admin, if 1, then allow. This will allow > > > users to acknowledge (permanently, if they must, using /etc/sysctl.conf) > > > that they've seen the syslog message about cap_sys_admin being > > > deprecated for syslog. > > > > > > Signed-off-by: Serge Hallyn <serge@hallyn.com> > > [...snip...] > > > James, do you mind taking this patch? > > Would it be possible to change the commit message to say that 1 would be > the default? Just to avoid future confusion... (having it at 0 default > later would just postpone the userspace breakage) > Good point, attached. >From ead9a1649880806c333b7f2378509d7d93725480 Mon Sep 17 00:00:00 2001 From: Serge Hallyn <serge@peq.(none)> Date: Thu, 3 Feb 2011 09:26:15 -0600 Subject: [PATCH 1/1] cap_syslog: don't refuse cap_sys_admin for now At 2.6.39 or 2.6.40, let's add a sysctl which defaults to 1. When 0, refuse if cap_sys_admin, if 1, then allow. Signed-off-by: Serge Hallyn <serge@hallyn.com> --- kernel/printk.c | 26 ++++++++++++++++---------- 1 files changed, 16 insertions(+), 10 deletions(-) diff --git a/kernel/printk.c b/kernel/printk.c index 2ddbdc7..bc56386 100644 --- a/kernel/printk.c +++ b/kernel/printk.c @@ -274,12 +274,24 @@ int do_syslog(int type, char __user *buf, int len, bool from_file) * at open time. */ if (type == SYSLOG_ACTION_OPEN || !from_file) { - if (dmesg_restrict && !capable(CAP_SYSLOG)) - goto warn; /* switch to return -EPERM after 2.6.39 */ + if (dmesg_restrict && !capable(CAP_SYSLOG)) { + /* remove after 2.6.39 */ + if (capable(CAP_SYS_ADMIN)) + WARN_ONCE(1, "Attempt to access syslog with CAP_SYS_ADMIN " + "but no CAP_SYSLOG (deprecated).\n"); + else + return -EPERM; + } if ((type != SYSLOG_ACTION_READ_ALL && type != SYSLOG_ACTION_SIZE_BUFFER) && - !capable(CAP_SYSLOG)) - goto warn; /* switch to return -EPERM after 2.6.39 */ + !capable(CAP_SYSLOG)) { + /* remove after 2.6.39 */ + if (capable(CAP_SYS_ADMIN)) + WARN_ONCE(1, "Attempt to access syslog with CAP_SYS_ADMIN " + "but no CAP_SYSLOG (deprecated).\n"); + else + return -EPERM; + } } error = security_syslog(type); @@ -423,12 +435,6 @@ int do_syslog(int type, char __user *buf, int len, bool from_file) } out: return error; -warn: - /* remove after 2.6.39 */ - if (capable(CAP_SYS_ADMIN)) - WARN_ONCE(1, "Attempt to access syslog with CAP_SYS_ADMIN " - "but no CAP_SYSLOG (deprecated and denied).\n"); - return -EPERM; } SYSCALL_DEFINE3(syslog, int, type, char __user *, buf, int, len) -- 1.7.2.3 ^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: CAP_SYSLOG, 2.6.38 and user space 2011-02-04 17:15 ` Serge E. Hallyn @ 2011-02-05 7:05 ` david 2011-02-06 1:18 ` Serge E. Hallyn 2011-02-09 19:50 ` Gergely Nagy 1 sibling, 1 reply; 27+ messages in thread From: david @ 2011-02-05 7:05 UTC (permalink / raw) To: Serge E. Hallyn; +Cc: Gergely Nagy, James Morris, Linux Kernel Mailing List On Fri, 4 Feb 2011, Serge E. Hallyn wrote: > Quoting Gergely Nagy (algernon@balabit.hu): >> On Fri, 2011-02-04 at 16:05 +0000, Serge E. Hallyn wrote: >>> Quoting Serge E. Hallyn (serge@hallyn.com): >>>>> From 2d7408541dd3a6e19a4265b028233789be6a40f4 Mon Sep 17 00:00:00 2001 >>>> From: Serge Hallyn <serge@peq.(none)> >>>> >>>> At 2.6.39 or 2.6.40, let's add a sysctl which defaults to 0. When >>>> 0, refuse if cap_sys_admin, if 1, then allow. This will allow >>>> users to acknowledge (permanently, if they must, using /etc/sysctl.conf) >>>> that they've seen the syslog message about cap_sys_admin being >>>> deprecated for syslog. >>>> >>>> Signed-off-by: Serge Hallyn <serge@hallyn.com> > - goto warn; /* switch to return -EPERM after 2.6.39 */ > + !capable(CAP_SYSLOG)) { > + /* remove after 2.6.39 */ > + if (capable(CAP_SYS_ADMIN)) > + WARN_ONCE(1, "Attempt to access syslog with CAP_SYS_ADMIN " > + "but no CAP_SYSLOG (deprecated).\n"); > + else > + return -EPERM; > + } > } why does this need to be removed after 2.6.39? whenever you go to remove it you will break userspace, what's the benifit of breaking userspace? I can understand that it's better to have a syslog daemon with CAP_SYSLOG instead of CAP_SYS_ADMIN, but does "it would be better to have userspace changed" really translate into "it's so important to have userspace changed that we need to break any userspace that hasn't changed"? I really don't think so. David Lang ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: CAP_SYSLOG, 2.6.38 and user space 2011-02-05 7:05 ` david @ 2011-02-06 1:18 ` Serge E. Hallyn 2011-02-09 21:23 ` Serge E. Hallyn 0 siblings, 1 reply; 27+ messages in thread From: Serge E. Hallyn @ 2011-02-06 1:18 UTC (permalink / raw) To: david Cc: Serge E. Hallyn, Gergely Nagy, James Morris, Linux Kernel Mailing List Quoting david@lang.hm (david@lang.hm): > On Fri, 4 Feb 2011, Serge E. Hallyn wrote: > > >Quoting Gergely Nagy (algernon@balabit.hu): > >>On Fri, 2011-02-04 at 16:05 +0000, Serge E. Hallyn wrote: > >>>Quoting Serge E. Hallyn (serge@hallyn.com): > >>>>>From 2d7408541dd3a6e19a4265b028233789be6a40f4 Mon Sep 17 00:00:00 2001 > >>>>From: Serge Hallyn <serge@peq.(none)> > >>>> > >>>>At 2.6.39 or 2.6.40, let's add a sysctl which defaults to 0. When > >>>>0, refuse if cap_sys_admin, if 1, then allow. This will allow > >>>>users to acknowledge (permanently, if they must, using /etc/sysctl.conf) > >>>>that they've seen the syslog message about cap_sys_admin being > >>>>deprecated for syslog. > >>>> > >>>>Signed-off-by: Serge Hallyn <serge@hallyn.com> > >- goto warn; /* switch to return -EPERM after 2.6.39 */ > >+ !capable(CAP_SYSLOG)) { > >+ /* remove after 2.6.39 */ > >+ if (capable(CAP_SYS_ADMIN)) > >+ WARN_ONCE(1, "Attempt to access syslog with CAP_SYS_ADMIN " > >+ "but no CAP_SYSLOG (deprecated).\n"); > >+ else > >+ return -EPERM; > >+ } > > } > > why does this need to be removed after 2.6.39? > > whenever you go to remove it you will break userspace, what's the > benifit of breaking userspace? > > I can understand that it's better to have a syslog daemon with > CAP_SYSLOG instead of CAP_SYS_ADMIN, but does "it would be better to > have userspace changed" really translate into "it's so important to > have userspace changed that we need to break any userspace that > hasn't changed"? > > I really don't think so. I think I agree with you. If someone wants to grant one of the other CAP_SYS_ADMIN powers without CAP_SYSLOG, then they can break that into yet another, i.e. CAP_IPCSET. Makes sense. thanks, -serge ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: CAP_SYSLOG, 2.6.38 and user space 2011-02-06 1:18 ` Serge E. Hallyn @ 2011-02-09 21:23 ` Serge E. Hallyn 2011-02-09 21:28 ` Gergely Nagy 0 siblings, 1 reply; 27+ messages in thread From: Serge E. Hallyn @ 2011-02-09 21:23 UTC (permalink / raw) To: Serge E. Hallyn Cc: david, Gergely Nagy, James Morris, Linux Kernel Mailing List Quoting Serge E. Hallyn (serge@hallyn.com): > Quoting david@lang.hm (david@lang.hm): > > On Fri, 4 Feb 2011, Serge E. Hallyn wrote: > > > > >Quoting Gergely Nagy (algernon@balabit.hu): > > >>On Fri, 2011-02-04 at 16:05 +0000, Serge E. Hallyn wrote: > > >>>Quoting Serge E. Hallyn (serge@hallyn.com): > > >>>>>From 2d7408541dd3a6e19a4265b028233789be6a40f4 Mon Sep 17 00:00:00 2001 > > >>>>From: Serge Hallyn <serge@peq.(none)> > > >>>> > > >>>>At 2.6.39 or 2.6.40, let's add a sysctl which defaults to 0. When > > >>>>0, refuse if cap_sys_admin, if 1, then allow. This will allow > > >>>>users to acknowledge (permanently, if they must, using /etc/sysctl.conf) > > >>>>that they've seen the syslog message about cap_sys_admin being > > >>>>deprecated for syslog. > > >>>> > > >>>>Signed-off-by: Serge Hallyn <serge@hallyn.com> > > >- goto warn; /* switch to return -EPERM after 2.6.39 */ > > >+ !capable(CAP_SYSLOG)) { > > >+ /* remove after 2.6.39 */ > > >+ if (capable(CAP_SYS_ADMIN)) > > >+ WARN_ONCE(1, "Attempt to access syslog with CAP_SYS_ADMIN " > > >+ "but no CAP_SYSLOG (deprecated).\n"); > > >+ else > > >+ return -EPERM; > > >+ } > > > } > > > > why does this need to be removed after 2.6.39? > > > > whenever you go to remove it you will break userspace, what's the > > benifit of breaking userspace? > > > > I can understand that it's better to have a syslog daemon with > > CAP_SYSLOG instead of CAP_SYS_ADMIN, but does "it would be better to > > have userspace changed" really translate into "it's so important to > > have userspace changed that we need to break any userspace that > > hasn't changed"? > > > > I really don't think so. > > I think I agree with you. If someone wants to grant one of the other > CAP_SYS_ADMIN powers without CAP_SYSLOG, then they can break that into > yet another, i.e. CAP_IPCSET. Makes sense. So if that's how we're leaning, then the following patch is much more concise. I'll send this to Linus and any appropriate -stable tomorrow if noone objects. >From 5166e114d6a7c508addbadd763322089eb0b02f5 Mon Sep 17 00:00:00 2001 From: Serge Hallyn <serge@hallyn.com> Date: Thu, 3 Feb 2011 09:26:15 -0600 Subject: [PATCH 1/1] cap_syslog: don't refuse cap_sys_admin for now (v2) It'd be nice to do that later, but it's not strictly necessary, and it'll be hard to do without breaking somebody's userspace. Signed-off-by: Serge Hallyn <serge@hallyn.com> --- kernel/printk.c | 14 ++++---------- 1 files changed, 4 insertions(+), 10 deletions(-) diff --git a/kernel/printk.c b/kernel/printk.c index 2ddbdc7..ff58136 100644 --- a/kernel/printk.c +++ b/kernel/printk.c @@ -274,12 +274,12 @@ int do_syslog(int type, char __user *buf, int len, bool from_file) * at open time. */ if (type == SYSLOG_ACTION_OPEN || !from_file) { - if (dmesg_restrict && !capable(CAP_SYSLOG)) - goto warn; /* switch to return -EPERM after 2.6.39 */ + if (dmesg_restrict && !capable(CAP_SYSLOG) && !capable(CAP_SYS_ADMIN)) + return -EPERM; if ((type != SYSLOG_ACTION_READ_ALL && type != SYSLOG_ACTION_SIZE_BUFFER) && - !capable(CAP_SYSLOG)) - goto warn; /* switch to return -EPERM after 2.6.39 */ + !capable(CAP_SYSLOG) && !capable(CAP_SYS_ADMIN)) + return -EPERM; } error = security_syslog(type); @@ -423,12 +423,6 @@ int do_syslog(int type, char __user *buf, int len, bool from_file) } out: return error; -warn: - /* remove after 2.6.39 */ - if (capable(CAP_SYS_ADMIN)) - WARN_ONCE(1, "Attempt to access syslog with CAP_SYS_ADMIN " - "but no CAP_SYSLOG (deprecated and denied).\n"); - return -EPERM; } SYSCALL_DEFINE3(syslog, int, type, char __user *, buf, int, len) -- 1.7.2.3 ^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: CAP_SYSLOG, 2.6.38 and user space 2011-02-09 21:23 ` Serge E. Hallyn @ 2011-02-09 21:28 ` Gergely Nagy 2011-02-09 21:34 ` david 2011-02-10 14:29 ` Serge E. Hallyn 0 siblings, 2 replies; 27+ messages in thread From: Gergely Nagy @ 2011-02-09 21:28 UTC (permalink / raw) To: Serge E. Hallyn; +Cc: david, James Morris, Linux Kernel Mailing List On Wed, 2011-02-09 at 21:23 +0000, Serge E. Hallyn wrote: > So if that's how we're leaning, then the following patch is much more > concise. I'll send this to Linus and any appropriate -stable tomorrow > if noone objects. > > From 5166e114d6a7c508addbadd763322089eb0b02f5 Mon Sep 17 00:00:00 2001 > From: Serge Hallyn <serge@hallyn.com> > Date: Thu, 3 Feb 2011 09:26:15 -0600 > Subject: [PATCH 1/1] cap_syslog: don't refuse cap_sys_admin for now (v2) > > It'd be nice to do that later, but it's not strictly necessary, > and it'll be hard to do without breaking somebody's userspace. > > Signed-off-by: Serge Hallyn <serge@hallyn.com> > --- > kernel/printk.c | 14 ++++---------- > 1 files changed, 4 insertions(+), 10 deletions(-) Personally, I'd prefer the sysctl idea in the long run, because userspace can easily and automatically adapt to the running kernel then. Ie, this patch is fine for 2.6.38, but later on, a sysctl could be introduced, that when set (but defaulting to unset, as to not break userspace), would make CAP_SYS_ADMIN return -EPERM. That way, syslogds could look at the setting, and act accordingly. This would mean that old userspace wouldn't break, and upgraded userspace could work on both old and new kernels, depending on the setting. Distros or admins could then enable the sysctl once they made sure that all neccessary applications have been upgraded. But this works too, for now. My immediate concern is making sure 2.6.38 doesn't break capability-using syslogds. -- |8] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: CAP_SYSLOG, 2.6.38 and user space 2011-02-09 21:28 ` Gergely Nagy @ 2011-02-09 21:34 ` david 2011-02-09 21:40 ` Gergely Nagy 2011-02-10 14:29 ` Serge E. Hallyn 1 sibling, 1 reply; 27+ messages in thread From: david @ 2011-02-09 21:34 UTC (permalink / raw) To: Gergely Nagy; +Cc: Serge E. Hallyn, James Morris, Linux Kernel Mailing List On Wed, 9 Feb 2011, Gergely Nagy wrote: > On Wed, 2011-02-09 at 21:23 +0000, Serge E. Hallyn wrote: >> So if that's how we're leaning, then the following patch is much more >> concise. I'll send this to Linus and any appropriate -stable tomorrow >> if noone objects. >> >> From 5166e114d6a7c508addbadd763322089eb0b02f5 Mon Sep 17 00:00:00 2001 >> From: Serge Hallyn <serge@hallyn.com> >> Date: Thu, 3 Feb 2011 09:26:15 -0600 >> Subject: [PATCH 1/1] cap_syslog: don't refuse cap_sys_admin for now (v2) >> >> It'd be nice to do that later, but it's not strictly necessary, >> and it'll be hard to do without breaking somebody's userspace. >> >> Signed-off-by: Serge Hallyn <serge@hallyn.com> >> --- >> kernel/printk.c | 14 ++++---------- >> 1 files changed, 4 insertions(+), 10 deletions(-) > > Personally, I'd prefer the sysctl idea in the long run, because > userspace can easily and automatically adapt to the running kernel then. > Ie, this patch is fine for 2.6.38, but later on, a sysctl could be > introduced, that when set (but defaulting to unset, as to not break > userspace), would make CAP_SYS_ADMIN return -EPERM. That way, syslogds > could look at the setting, and act accordingly. This would mean that old > userspace wouldn't break, and upgraded userspace could work on both old > and new kernels, depending on the setting. Distros or admins could then > enable the sysctl once they made sure that all neccessary applications > have been upgraded. what is your justification for ever having CAP_SYS_ADMIN return -EPERM? what's the value in blocking this. David Lang > But this works too, for now. My immediate concern is making sure 2.6.38 > doesn't break capability-using syslogds. > > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: CAP_SYSLOG, 2.6.38 and user space 2011-02-09 21:34 ` david @ 2011-02-09 21:40 ` Gergely Nagy 2011-02-09 21:47 ` david 0 siblings, 1 reply; 27+ messages in thread From: Gergely Nagy @ 2011-02-09 21:40 UTC (permalink / raw) To: david; +Cc: Serge E. Hallyn, James Morris, Linux Kernel Mailing List On Wed, 2011-02-09 at 13:34 -0800, david@lang.hm wrote: > On Wed, 9 Feb 2011, Gergely Nagy wrote: > > > On Wed, 2011-02-09 at 21:23 +0000, Serge E. Hallyn wrote: > >> So if that's how we're leaning, then the following patch is much more > >> concise. I'll send this to Linus and any appropriate -stable tomorrow > >> if noone objects. > >> > >> From 5166e114d6a7c508addbadd763322089eb0b02f5 Mon Sep 17 00:00:00 2001 > >> From: Serge Hallyn <serge@hallyn.com> > >> Date: Thu, 3 Feb 2011 09:26:15 -0600 > >> Subject: [PATCH 1/1] cap_syslog: don't refuse cap_sys_admin for now (v2) > >> > >> It'd be nice to do that later, but it's not strictly necessary, > >> and it'll be hard to do without breaking somebody's userspace. > >> > >> Signed-off-by: Serge Hallyn <serge@hallyn.com> > >> --- > >> kernel/printk.c | 14 ++++---------- > >> 1 files changed, 4 insertions(+), 10 deletions(-) > > > > Personally, I'd prefer the sysctl idea in the long run, because > > userspace can easily and automatically adapt to the running kernel then. > > Ie, this patch is fine for 2.6.38, but later on, a sysctl could be > > introduced, that when set (but defaulting to unset, as to not break > > userspace), would make CAP_SYS_ADMIN return -EPERM. That way, syslogds > > could look at the setting, and act accordingly. This would mean that old > > userspace wouldn't break, and upgraded userspace could work on both old > > and new kernels, depending on the setting. Distros or admins could then > > enable the sysctl once they made sure that all neccessary applications > > have been upgraded. > > what is your justification for ever having CAP_SYS_ADMIN return -EPERM? > what's the value in blocking this. Nothing. Come to think of it, the main use of the sysctl would be to detect CAP_SYSLOG support, so that applications can drop CAP_SYS_ADMIN and use CAP_SYSLOG only (which, imo, is a good idea - the less capabilities, the better, and CAP_SYS_ADMIN is quite broad when one only wants CAP_SYSLOG). If there's a better way to allow userspace to easily detect CAP_SYSLOG, I'm all for that. -- |8] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: CAP_SYSLOG, 2.6.38 and user space 2011-02-09 21:40 ` Gergely Nagy @ 2011-02-09 21:47 ` david 2011-02-09 22:04 ` Gergely Nagy 0 siblings, 1 reply; 27+ messages in thread From: david @ 2011-02-09 21:47 UTC (permalink / raw) To: Gergely Nagy; +Cc: Serge E. Hallyn, James Morris, Linux Kernel Mailing List On Wed, 9 Feb 2011, Gergely Nagy wrote: > On Wed, 2011-02-09 at 13:34 -0800, david@lang.hm wrote: >> On Wed, 9 Feb 2011, Gergely Nagy wrote: >> >>> On Wed, 2011-02-09 at 21:23 +0000, Serge E. Hallyn wrote: >>>> So if that's how we're leaning, then the following patch is much more >>>> concise. I'll send this to Linus and any appropriate -stable tomorrow >>>> if noone objects. >>>> >>>> From 5166e114d6a7c508addbadd763322089eb0b02f5 Mon Sep 17 00:00:00 2001 >>>> From: Serge Hallyn <serge@hallyn.com> >>>> Date: Thu, 3 Feb 2011 09:26:15 -0600 >>>> Subject: [PATCH 1/1] cap_syslog: don't refuse cap_sys_admin for now (v2) >>>> >>>> It'd be nice to do that later, but it's not strictly necessary, >>>> and it'll be hard to do without breaking somebody's userspace. >>>> >>>> Signed-off-by: Serge Hallyn <serge@hallyn.com> >>>> --- >>>> kernel/printk.c | 14 ++++---------- >>>> 1 files changed, 4 insertions(+), 10 deletions(-) >>> >>> Personally, I'd prefer the sysctl idea in the long run, because >>> userspace can easily and automatically adapt to the running kernel then. >>> Ie, this patch is fine for 2.6.38, but later on, a sysctl could be >>> introduced, that when set (but defaulting to unset, as to not break >>> userspace), would make CAP_SYS_ADMIN return -EPERM. That way, syslogds >>> could look at the setting, and act accordingly. This would mean that old >>> userspace wouldn't break, and upgraded userspace could work on both old >>> and new kernels, depending on the setting. Distros or admins could then >>> enable the sysctl once they made sure that all neccessary applications >>> have been upgraded. >> >> what is your justification for ever having CAP_SYS_ADMIN return -EPERM? >> what's the value in blocking this. > > Nothing. Come to think of it, the main use of the sysctl would be to > detect CAP_SYSLOG support, so that applications can drop CAP_SYS_ADMIN > and use CAP_SYSLOG only (which, imo, is a good idea - the less > capabilities, the better, and CAP_SYS_ADMIN is quite broad when one only > wants CAP_SYSLOG). > > If there's a better way to allow userspace to easily detect CAP_SYSLOG, > I'm all for that. if userspace wants to detect this, what is wrong with them checking for a kernel >= 2.6.38? realistically, if the upstream applications (which need to work with many different versions) just support having CAP_SYS_ADMIN, it would be a very minor distro patch to change this to CAP_SYSLOG for a distro release where the distro _knows_ that they don't have to support an older kernel. David Lang ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: CAP_SYSLOG, 2.6.38 and user space 2011-02-09 21:47 ` david @ 2011-02-09 22:04 ` Gergely Nagy 2011-02-09 22:27 ` david 0 siblings, 1 reply; 27+ messages in thread From: Gergely Nagy @ 2011-02-09 22:04 UTC (permalink / raw) To: david; +Cc: Serge E. Hallyn, James Morris, Linux Kernel Mailing List On Wed, 2011-02-09 at 13:47 -0800, david@lang.hm wrote: > On Wed, 9 Feb 2011, Gergely Nagy wrote: > > > On Wed, 2011-02-09 at 13:34 -0800, david@lang.hm wrote: > >> On Wed, 9 Feb 2011, Gergely Nagy wrote: > >> > >>> On Wed, 2011-02-09 at 21:23 +0000, Serge E. Hallyn wrote: > >>>> So if that's how we're leaning, then the following patch is much more > >>>> concise. I'll send this to Linus and any appropriate -stable tomorrow > >>>> if noone objects. > >>>> > >>>> From 5166e114d6a7c508addbadd763322089eb0b02f5 Mon Sep 17 00:00:00 2001 > >>>> From: Serge Hallyn <serge@hallyn.com> > >>>> Date: Thu, 3 Feb 2011 09:26:15 -0600 > >>>> Subject: [PATCH 1/1] cap_syslog: don't refuse cap_sys_admin for now (v2) > >>>> > >>>> It'd be nice to do that later, but it's not strictly necessary, > >>>> and it'll be hard to do without breaking somebody's userspace. > >>>> > >>>> Signed-off-by: Serge Hallyn <serge@hallyn.com> > >>>> --- > >>>> kernel/printk.c | 14 ++++---------- > >>>> 1 files changed, 4 insertions(+), 10 deletions(-) > >>> > >>> Personally, I'd prefer the sysctl idea in the long run, because > >>> userspace can easily and automatically adapt to the running kernel then. > >>> Ie, this patch is fine for 2.6.38, but later on, a sysctl could be > >>> introduced, that when set (but defaulting to unset, as to not break > >>> userspace), would make CAP_SYS_ADMIN return -EPERM. That way, syslogds > >>> could look at the setting, and act accordingly. This would mean that old > >>> userspace wouldn't break, and upgraded userspace could work on both old > >>> and new kernels, depending on the setting. Distros or admins could then > >>> enable the sysctl once they made sure that all neccessary applications > >>> have been upgraded. > >> > >> what is your justification for ever having CAP_SYS_ADMIN return -EPERM? > >> what's the value in blocking this. > > > > Nothing. Come to think of it, the main use of the sysctl would be to > > detect CAP_SYSLOG support, so that applications can drop CAP_SYS_ADMIN > > and use CAP_SYSLOG only (which, imo, is a good idea - the less > > capabilities, the better, and CAP_SYS_ADMIN is quite broad when one only > > wants CAP_SYSLOG). > > > > If there's a better way to allow userspace to easily detect CAP_SYSLOG, > > I'm all for that. > > if userspace wants to detect this, what is wrong with them checking for a > kernel >= 2.6.38? How do I do that, apart from parsing utsname, which I find insultingly ugly? It might be just me, but I very much prefer feature tests over version sniffing. > realistically, if the upstream applications (which need to work with many > different versions) just support having CAP_SYS_ADMIN, it would be a very > minor distro patch to change this to CAP_SYSLOG for a distro release where > the distro _knows_ that they don't have to support an older kernel. That is, indeed, true, and works for distros. But when a software vendor provides binaries aswell as source, they do have to support older kernels too. And even if that is possible with CAP_SYS_ADMIN, I'd still prefer CAP_SYSLOG, if available. Thus, being able to easily adapt is something I'm very interested in. If that's not possible, using CAP_SYS_ADMIN for a long long time still is the second best option. I also wish to place as little burden on distros as possible, so delegating the decision to them does not appeal to me that much. It's certainly an option, but I'm sure we can do better than that. -- |8] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: CAP_SYSLOG, 2.6.38 and user space 2011-02-09 22:04 ` Gergely Nagy @ 2011-02-09 22:27 ` david 2011-02-09 22:37 ` Gergely Nagy 0 siblings, 1 reply; 27+ messages in thread From: david @ 2011-02-09 22:27 UTC (permalink / raw) To: Gergely Nagy; +Cc: Serge E. Hallyn, James Morris, Linux Kernel Mailing List On Wed, 9 Feb 2011, Gergely Nagy wrote: > On Wed, 2011-02-09 at 13:47 -0800, david@lang.hm wrote: >> On Wed, 9 Feb 2011, Gergely Nagy wrote: >> >>> On Wed, 2011-02-09 at 13:34 -0800, david@lang.hm wrote: >>>> On Wed, 9 Feb 2011, Gergely Nagy wrote: >>>> >>>>> On Wed, 2011-02-09 at 21:23 +0000, Serge E. Hallyn wrote: >>>>>> So if that's how we're leaning, then the following patch is much more >>>>>> concise. I'll send this to Linus and any appropriate -stable tomorrow >>>>>> if noone objects. >>>>>> >>>>>> From 5166e114d6a7c508addbadd763322089eb0b02f5 Mon Sep 17 00:00:00 2001 >>>>>> From: Serge Hallyn <serge@hallyn.com> >>>>>> Date: Thu, 3 Feb 2011 09:26:15 -0600 >>>>>> Subject: [PATCH 1/1] cap_syslog: don't refuse cap_sys_admin for now (v2) >>>>>> >>>>>> It'd be nice to do that later, but it's not strictly necessary, >>>>>> and it'll be hard to do without breaking somebody's userspace. >>>>>> >>>>>> Signed-off-by: Serge Hallyn <serge@hallyn.com> >>>>>> --- >>>>>> kernel/printk.c | 14 ++++---------- >>>>>> 1 files changed, 4 insertions(+), 10 deletions(-) >>>>> >>>>> Personally, I'd prefer the sysctl idea in the long run, because >>>>> userspace can easily and automatically adapt to the running kernel then. >>>>> Ie, this patch is fine for 2.6.38, but later on, a sysctl could be >>>>> introduced, that when set (but defaulting to unset, as to not break >>>>> userspace), would make CAP_SYS_ADMIN return -EPERM. That way, syslogds >>>>> could look at the setting, and act accordingly. This would mean that old >>>>> userspace wouldn't break, and upgraded userspace could work on both old >>>>> and new kernels, depending on the setting. Distros or admins could then >>>>> enable the sysctl once they made sure that all neccessary applications >>>>> have been upgraded. >>>> >>>> what is your justification for ever having CAP_SYS_ADMIN return -EPERM? >>>> what's the value in blocking this. >>> >>> Nothing. Come to think of it, the main use of the sysctl would be to >>> detect CAP_SYSLOG support, so that applications can drop CAP_SYS_ADMIN >>> and use CAP_SYSLOG only (which, imo, is a good idea - the less >>> capabilities, the better, and CAP_SYS_ADMIN is quite broad when one only >>> wants CAP_SYSLOG). >>> >>> If there's a better way to allow userspace to easily detect CAP_SYSLOG, >>> I'm all for that. >> >> if userspace wants to detect this, what is wrong with them checking for a >> kernel >= 2.6.38? > > How do I do that, apart from parsing utsname, which I find insultingly > ugly? It might be just me, but I very much prefer feature tests over > version sniffing. > >> realistically, if the upstream applications (which need to work with many >> different versions) just support having CAP_SYS_ADMIN, it would be a very >> minor distro patch to change this to CAP_SYSLOG for a distro release where >> the distro _knows_ that they don't have to support an older kernel. > > That is, indeed, true, and works for distros. But when a software vendor > provides binaries aswell as source, they do have to support older > kernels too. And even if that is possible with CAP_SYS_ADMIN, I'd still > prefer CAP_SYSLOG, if available. > > Thus, being able to easily adapt is something I'm very interested in. If > that's not possible, using CAP_SYS_ADMIN for a long long time still is > the second best option. what's wrong with doing a runtime test at startup that tries to read with CAP_SYS_ADMIN and if you get -EPERM trying again with CAP_SYSLOG? creating an ioctl for something like this seems like it's significantly overcomplicating the issue. > I also wish to place as little burden on distros as possible, so > delegating the decision to them does not appeal to me that much. It's > certainly an option, but I'm sure we can do better than that. but why maintain an ioctl forever for something that nobody should care about in a few years? David Lang ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: CAP_SYSLOG, 2.6.38 and user space 2011-02-09 22:27 ` david @ 2011-02-09 22:37 ` Gergely Nagy 0 siblings, 0 replies; 27+ messages in thread From: Gergely Nagy @ 2011-02-09 22:37 UTC (permalink / raw) To: david; +Cc: Serge E. Hallyn, James Morris, Linux Kernel Mailing List > what's wrong with doing a runtime test at startup that tries to read with > CAP_SYS_ADMIN and if you get -EPERM trying again with CAP_SYSLOG? That's also an option I considered, and might end up doing if there's no easier option. In my case, though, due to the design of the code, it's not trivially simple to do that (it isn't particularly hard, either, but such a test wouldn't be my first choice). > creating an ioctl for something like this seems like it's significantly > overcomplicating the issue. True. Nevertheless, like I said before: my main concern is making sure userspace doesn't break. Figuring out how to support CAP_SYSLOG best is a much lower priority on my list, and I haven't given it all that much thought. I'd prefer an ioctl or something similar which I can easily query, without having to resort to trial and error or version sniffing. But I understand that's not the best option from a kernel PoV, so falling back to trying to read at startup is an acceptable solution aswell. So, yeah... I suppose simply introducing CAP_SYSLOG, and keeping CAP_SYS_ADMIN as it is would work just fine. -- |8] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: CAP_SYSLOG, 2.6.38 and user space 2011-02-09 21:28 ` Gergely Nagy 2011-02-09 21:34 ` david @ 2011-02-10 14:29 ` Serge E. Hallyn 1 sibling, 0 replies; 27+ messages in thread From: Serge E. Hallyn @ 2011-02-10 14:29 UTC (permalink / raw) To: Gergely Nagy Cc: Serge E. Hallyn, david, James Morris, Linux Kernel Mailing List Quoting Gergely Nagy (algernon@balabit.hu): > On Wed, 2011-02-09 at 21:23 +0000, Serge E. Hallyn wrote: > > So if that's how we're leaning, then the following patch is much more > > concise. I'll send this to Linus and any appropriate -stable tomorrow > > if noone objects. > > > > From 5166e114d6a7c508addbadd763322089eb0b02f5 Mon Sep 17 00:00:00 2001 > > From: Serge Hallyn <serge@hallyn.com> > > Date: Thu, 3 Feb 2011 09:26:15 -0600 > > Subject: [PATCH 1/1] cap_syslog: don't refuse cap_sys_admin for now (v2) > > > > It'd be nice to do that later, but it's not strictly necessary, > > and it'll be hard to do without breaking somebody's userspace. > > > > Signed-off-by: Serge Hallyn <serge@hallyn.com> > > --- > > kernel/printk.c | 14 ++++---------- > > 1 files changed, 4 insertions(+), 10 deletions(-) > > Personally, I'd prefer the sysctl idea in the long run, because > userspace can easily and automatically adapt to the running kernel then. > Ie, this patch is fine for 2.6.38, but later on, a sysctl could be > introduced, that when set (but defaulting to unset, as to not break > userspace), would make CAP_SYS_ADMIN return -EPERM. That way, syslogds > could look at the setting, and act accordingly. This would mean that old > userspace wouldn't break, and upgraded userspace could work on both old > and new kernels, depending on the setting. Distros or admins could then > enable the sysctl once they made sure that all neccessary applications > have been upgraded. > > But this works too, for now. My immediate concern is making sure 2.6.38 > doesn't break capability-using syslogds. Ok, I'll forward the previous patch. thanks, -serge ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: CAP_SYSLOG, 2.6.38 and user space 2011-02-04 17:15 ` Serge E. Hallyn 2011-02-05 7:05 ` david @ 2011-02-09 19:50 ` Gergely Nagy 1 sibling, 0 replies; 27+ messages in thread From: Gergely Nagy @ 2011-02-09 19:50 UTC (permalink / raw) To: Serge E. Hallyn; +Cc: James Morris, Linux Kernel Mailing List On Fri, 2011-02-04 at 17:15 +0000, Serge E. Hallyn wrote: [...snip...] > > > James, do you mind taking this patch? > > > > Would it be possible to change the commit message to say that 1 would be > > the default? Just to avoid future confusion... (having it at 0 default > > later would just postpone the userspace breakage) > > > > Good point, attached. [...snip...] Just a friendly reminder that - as far as I see - neither this, nor anything similar, did not make it into Linus' tree yet. I'd love if it would, would hate to tell users to avoid 2.6.38 due to it being broken. -- |8] ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2011-02-10 14:28 UTC | newest] Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-02-03 11:39 CAP_SYSLOG, 2.6.38 and user space Gergely Nagy 2011-02-03 15:13 ` Alan Cox 2011-02-03 15:32 ` Serge E. Hallyn 2011-02-03 15:53 ` Gergely Nagy 2011-02-03 16:51 ` Serge E. Hallyn 2011-02-03 17:07 ` Gergely Nagy 2011-02-04 0:49 ` david 2011-02-04 8:03 ` Marc Koschewski 2011-02-04 8:40 ` Gergely Nagy 2011-02-04 11:08 ` Alan Cox 2011-02-04 16:03 ` Serge E. Hallyn 2011-02-03 15:54 ` Nick Bowler 2011-02-04 16:05 ` Serge E. Hallyn 2011-02-04 16:33 ` Gergely Nagy 2011-02-04 17:15 ` Serge E. Hallyn 2011-02-05 7:05 ` david 2011-02-06 1:18 ` Serge E. Hallyn 2011-02-09 21:23 ` Serge E. Hallyn 2011-02-09 21:28 ` Gergely Nagy 2011-02-09 21:34 ` david 2011-02-09 21:40 ` Gergely Nagy 2011-02-09 21:47 ` david 2011-02-09 22:04 ` Gergely Nagy 2011-02-09 22:27 ` david 2011-02-09 22:37 ` Gergely Nagy 2011-02-10 14:29 ` Serge E. Hallyn 2011-02-09 19:50 ` Gergely Nagy
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.