CAP_SYSLOG, 2.6.38 and user space
Gergely Nagy
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 majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Alan Cox
Gergely Nagy <alge...@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
Serge E. Hallyn
> 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 <se...@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
Gergely Nagy
> > 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]
Nick Bowler
> 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/)
Serge E. Hallyn
> 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
Gergely Nagy
> > > 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]
da...@lang.hm
> Quoting Gergely Nagy (alge...@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
Marc Koschewski
* da...@lang.hm <da...@lang.hm> [2011-02-03 16:49:08 -0800]:
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 majo...@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
Gergely Nagy
> 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]
Alan Cox
> 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
Serge E. Hallyn
James, do you mind taking this patch?
thanks,
-serge
Serge E. Hallyn
> 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
Gergely Nagy
> Quoting Serge E. Hallyn (se...@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 <se...@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]
Serge E. Hallyn
> On Fri, 2011-02-04 at 16:05 +0000, Serge E. Hallyn wrote:
> > Quoting Serge E. Hallyn (se...@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 <se...@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 <se...@hallyn.com>
--
da...@lang.hm
> Quoting Gergely Nagy (alge...@balabit.hu):
>> On Fri, 2011-02-04 at 16:05 +0000, Serge E. Hallyn wrote:
>>> Quoting Serge E. Hallyn (se...@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 <se...@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
Serge E. Hallyn
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
Gergely Nagy
[...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.
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]
Serge E. Hallyn
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 <se...@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 <se...@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
--
Gergely Nagy
> 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 <se...@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 <se...@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]
da...@lang.hm
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.
>
>
--
da...@lang.hm
> 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
Gergely Nagy
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]
Gergely Nagy
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]
da...@lang.hm
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
Gergely Nagy
> 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]
Serge E. Hallyn
Ok, I'll forward the previous patch.
thanks,
-serge