Re: Posix file capabilities in 2.6.24rc2; now 2.6.24-rc3
On Tue, 20 Nov 2007 16:51:21 -0600 "Serge E. Hallyn" <[EMAIL PROTECTED]> wrote: > Quoting Chris Friedhoff ([EMAIL PROTECTED]): > > On Tue, 20 Nov 2007 08:51:06 -0600 > > "Serge E. Hallyn" <[EMAIL PROTECTED]> wrote: > > > > > Quoting Chris Friedhoff ([EMAIL PROTECTED]): > > > > On Mon, 19 Nov 2007 17:16:44 -0600 > > > > "Serge E. Hallyn" <[EMAIL PROTECTED]> wrote: > > > > > > > > > Quoting Chris Friedhoff ([EMAIL PROTECTED]): > > > > > > Hello Serge, > > > > > > > > > > > > just to let you know: with 2.6.24-rc3 I have the same problem. > > > > > > > > > > Ok, so here is the flow. > > > > > > > > > > First off, using runlevel 5 on FC7, using 'log out' correctly brings > > > > > you back to a new login prompt. Your problem is starting in runlevel > > > > > 3, and typing 'xinit .xinitrc'; when you exit your wm, xinit is not > > > > > allowed to kill X so you don't get back to your console. > > > > > > > > Yes, I'm booting in a runlevel without a session manager and starting > > > > my X session with xinit. > > > > (slackware: console->runlevel 3; sessionmanager->runlevel 4 ) > > > > > > > > > > > > > > First comment is, as you point out on your homepage, you could > > > > > setfcaps -c cap_kill+p -e /usr/bin/xinit > > > > > Then xinit is allowed to kill X. Yes xinit forks and execs a > > > > > user-writable script, but of course upon the exec to start the script > > > > > cap_kill is lost, so the user can't abuse this. > > > > > > > > > > Since you pointed this out on your homepage, I have to assume you've > > > > > decided you don't want to give cap_kill to xinit? > > > > > > > > No, since I'm using capabilities and I'm very happy with it, I grant > > > > cap_kill to xinit. For myself the problem is solved ... > > > > > > > > > > > > > > My other question is - do we want to maintain this signal restriction? > > > > > So long as a privileged process isn't dumpable, is it any more > > > > > dangerous > > > > > for user hallyn to kill capability-raised process owned by hallyn than > > > > > it is to kill a setuid process started by hallyn? If we decide no, > > > > > then > > > > > maybe we should remove cap_task_kill() as well as the > > > > > cap_task_setnice(), > > > > > cap_task_setioprio(), cap_task_setscheduler()? > > > > > > > > > > Or maybe i've just forgotten a compelling scenario... > > > > > > > > > > thanks, > > > > > -serge > > > > > > > > > > > > ... but if some user decides to configure capabilities into the 2.6.24 > > > > kernel or just uses such a kernel and > > > > 1) is not granting cap_kill to xinit, and > > > > 2) starts X by issuing xinit on the console > > > > 3) ends after some time his X session, to come back to the console > > > > > > > > he will see a different behavior compared to 2.6.23 exiting his X > > > > session and (I think) believes to have a bug in the X package. > > > > > > > > Andrew Morton describes the problem here, too: > > > > http://lkml.org/lkml/2006/11/23/15 > > > > http://lkml.org/lkml/2006/11/23/19 > > > > > > > > Am I wrong in the assumption, but should one not accept an unchanged > > > > behavior with or without capabilities in the kernel regarding the > > > > behavior of applications, when he is not actually using (by not setting > > > > the xattr capability) capabilities with this application? > > > > > > > > If I'm wrong, maybe a warning or hint should be given that one has to > > > > grant cap_kill to xinit to come back to the console if the X session > > > > was started by xinit. > > > > > > Thanks - yes, I see (I tend to get lost in my testruns). So we're back to > > > trying to do the fix I was trying to do along with the SIGCONT fix a few > > > weeks ago. > > > > > > The problem is that when you run a setuid binary, its pP and pE are > > > fully raised. The following patch fixes it for me. Chris, does it fix > > > your problem? > > > > Yes, this patch fixes it for me, too. > > > > Thanks, > > > > Chris > > Thanks for the valuable testing and bugreports, Chris. You're welcome! Chris > > If I don't hear any counter-arguments I'll post the patch in its own > thread tomorrow. > > -serge Chris Friedhoff [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Posix file capabilities in 2.6.24rc2; now 2.6.24-rc3
On Tue, 20 Nov 2007 08:51:06 -0600 "Serge E. Hallyn" <[EMAIL PROTECTED]> wrote: > Quoting Chris Friedhoff ([EMAIL PROTECTED]): > > On Mon, 19 Nov 2007 17:16:44 -0600 > > "Serge E. Hallyn" <[EMAIL PROTECTED]> wrote: > > > > > Quoting Chris Friedhoff ([EMAIL PROTECTED]): > > > > Hello Serge, > > > > > > > > just to let you know: with 2.6.24-rc3 I have the same problem. > > > > > > Ok, so here is the flow. > > > > > > First off, using runlevel 5 on FC7, using 'log out' correctly brings > > > you back to a new login prompt. Your problem is starting in runlevel > > > 3, and typing 'xinit .xinitrc'; when you exit your wm, xinit is not > > > allowed to kill X so you don't get back to your console. > > > > Yes, I'm booting in a runlevel without a session manager and starting > > my X session with xinit. > > (slackware: console->runlevel 3; sessionmanager->runlevel 4 ) > > > > > > > > First comment is, as you point out on your homepage, you could > > > setfcaps -c cap_kill+p -e /usr/bin/xinit > > > Then xinit is allowed to kill X. Yes xinit forks and execs a > > > user-writable script, but of course upon the exec to start the script > > > cap_kill is lost, so the user can't abuse this. > > > > > > Since you pointed this out on your homepage, I have to assume you've > > > decided you don't want to give cap_kill to xinit? > > > > No, since I'm using capabilities and I'm very happy with it, I grant > > cap_kill to xinit. For myself the problem is solved ... > > > > > > > > My other question is - do we want to maintain this signal restriction? > > > So long as a privileged process isn't dumpable, is it any more dangerous > > > for user hallyn to kill capability-raised process owned by hallyn than > > > it is to kill a setuid process started by hallyn? If we decide no, then > > > maybe we should remove cap_task_kill() as well as the cap_task_setnice(), > > > cap_task_setioprio(), cap_task_setscheduler()? > > > > > > Or maybe i've just forgotten a compelling scenario... > > > > > > thanks, > > > -serge > > > > > > ... but if some user decides to configure capabilities into the 2.6.24 > > kernel or just uses such a kernel and > > 1) is not granting cap_kill to xinit, and > > 2) starts X by issuing xinit on the console > > 3) ends after some time his X session, to come back to the console > > > > he will see a different behavior compared to 2.6.23 exiting his X > > session and (I think) believes to have a bug in the X package. > > > > Andrew Morton describes the problem here, too: > > http://lkml.org/lkml/2006/11/23/15 > > http://lkml.org/lkml/2006/11/23/19 > > > > Am I wrong in the assumption, but should one not accept an unchanged > > behavior with or without capabilities in the kernel regarding the > > behavior of applications, when he is not actually using (by not setting > > the xattr capability) capabilities with this application? > > > > If I'm wrong, maybe a warning or hint should be given that one has to > > grant cap_kill to xinit to come back to the console if the X session > > was started by xinit. > > Thanks - yes, I see (I tend to get lost in my testruns). So we're back to > trying to do the fix I was trying to do along with the SIGCONT fix a few > weeks ago. > > The problem is that when you run a setuid binary, its pP and pE are > fully raised. The following patch fixes it for me. Chris, does it fix > your problem? Yes, this patch fixes it for me, too. Thanks, Chris > Andrew, am I again confusing myself and doing something > unsafe? > > thanks, > -serge > > >From d0b931776c0c424e583bf736d6a2498be4eccb98 Mon Sep 17 00:00:00 2001 > From: Serge E. Hallyn <[EMAIL PROTECTED]> > Date: Tue, 20 Nov 2007 08:47:35 + > Subject: [PATCH 1/1] file capabilities: don't prevent signaling setuid root > programs. > > When an unprivileged user runs a setuid root program in !SECURE_NOROOT > mode, fP, fI, and fE are set full on, so pP' and pE' are full on. > Then cap_task_kill() prevents the user from signaling the setuid root > task. This is a change in behavior compared to when > !CONFIG_SECURITY_FILE_CAPABILITIES. > > This patch introduces a special check into cap_task_kill() just > to check whether a non-root user is signaling a setuid root > program started by the same user. If so, then signal is allowed. > > This still leaves open the
Re: 2.6.24-rc2 STD with s2disk fails to activate suspended system after loading - now 2.6.24-rc3
The patch http://bugzilla.kernel.org/attachment.cgi?id=13652=view from Comment #16 of http://bugzilla.kernel.org/show_bug.cgi?id=9345 also works for me and enables successful s2disk cycles. Tested with 6 cycles, 3 from console and than 3 from within X. Thanks, Chris On Tue, 20 Nov 2007 00:58:29 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote: > On Monday, 19 of November 2007, Chris Friedhoff wrote: > > dmesg output is added. > > > > increasing CONFIG_BLK_DEV_RAM_SIZE from to 131072 hasn't changed > > the non-functioning of 2.6.24-rc3 > > > > s2disk works with 2.6.23.8 ; I tested 4 cycles in a row, 2 from console > > and 2 from within X > > I've attached a patch to the bugzilla entry, please test it. > > Thanks, > Rafael Chris Friedhoff [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc2 STD with s2disk fails to activate suspended system after loading - now 2.6.24-rc3
the patch on top of 2.6.24-rc3 fixed the problem. now I can succesfully s2disk. I tested it 5 times in a row, 2 from the console and 3 from within X thanks for fixing it, Chris On Tue, 20 Nov 2007 00:58:29 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote: > On Monday, 19 of November 2007, Chris Friedhoff wrote: > > dmesg output is added. > > > > increasing CONFIG_BLK_DEV_RAM_SIZE from to 131072 hasn't changed > > the non-functioning of 2.6.24-rc3 > > > > s2disk works with 2.6.23.8 ; I tested 4 cycles in a row, 2 from console > > and 2 from within X > > I've attached a patch to the bugzilla entry, please test it. > > Thanks, > Rafael Chris Friedhoff [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Posix file capabilities in 2.6.24rc2; now 2.6.24-rc3
On Mon, 19 Nov 2007 17:16:44 -0600 "Serge E. Hallyn" <[EMAIL PROTECTED]> wrote: > Quoting Chris Friedhoff ([EMAIL PROTECTED]): > > Hello Serge, > > > > just to let you know: with 2.6.24-rc3 I have the same problem. > > Ok, so here is the flow. > > First off, using runlevel 5 on FC7, using 'log out' correctly brings > you back to a new login prompt. Your problem is starting in runlevel > 3, and typing 'xinit .xinitrc'; when you exit your wm, xinit is not > allowed to kill X so you don't get back to your console. Yes, I'm booting in a runlevel without a session manager and starting my X session with xinit. (slackware: console->runlevel 3; sessionmanager->runlevel 4 ) > > First comment is, as you point out on your homepage, you could > setfcaps -c cap_kill+p -e /usr/bin/xinit > Then xinit is allowed to kill X. Yes xinit forks and execs a > user-writable script, but of course upon the exec to start the script > cap_kill is lost, so the user can't abuse this. > > Since you pointed this out on your homepage, I have to assume you've > decided you don't want to give cap_kill to xinit? No, since I'm using capabilities and I'm very happy with it, I grant cap_kill to xinit. For myself the problem is solved ... > > My other question is - do we want to maintain this signal restriction? > So long as a privileged process isn't dumpable, is it any more dangerous > for user hallyn to kill capability-raised process owned by hallyn than > it is to kill a setuid process started by hallyn? If we decide no, then > maybe we should remove cap_task_kill() as well as the cap_task_setnice(), > cap_task_setioprio(), cap_task_setscheduler()? > > Or maybe i've just forgotten a compelling scenario... > > thanks, > -serge ... but if some user decides to configure capabilities into the 2.6.24 kernel or just uses such a kernel and 1) is not granting cap_kill to xinit, and 2) starts X by issuing xinit on the console 3) ends after some time his X session, to come back to the console he will see a different behavior compared to 2.6.23 exiting his X session and (I think) believes to have a bug in the X package. Andrew Morton describes the problem here, too: http://lkml.org/lkml/2006/11/23/15 http://lkml.org/lkml/2006/11/23/19 Am I wrong in the assumption, but should one not accept an unchanged behavior with or without capabilities in the kernel regarding the behavior of applications, when he is not actually using (by not setting the xattr capability) capabilities with this application? If I'm wrong, maybe a warning or hint should be given that one has to grant cap_kill to xinit to come back to the console if the X session was started by xinit. Chris Chris Friedhoff [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Posix file capabilities in 2.6.24rc2; now 2.6.24-rc3
On Mon, 19 Nov 2007 17:16:44 -0600 Serge E. Hallyn [EMAIL PROTECTED] wrote: Quoting Chris Friedhoff ([EMAIL PROTECTED]): Hello Serge, just to let you know: with 2.6.24-rc3 I have the same problem. Ok, so here is the flow. First off, using runlevel 5 on FC7, using 'log out' correctly brings you back to a new login prompt. Your problem is starting in runlevel 3, and typing 'xinit .xinitrc'; when you exit your wm, xinit is not allowed to kill X so you don't get back to your console. Yes, I'm booting in a runlevel without a session manager and starting my X session with xinit. (slackware: console-runlevel 3; sessionmanager-runlevel 4 ) First comment is, as you point out on your homepage, you could setfcaps -c cap_kill+p -e /usr/bin/xinit Then xinit is allowed to kill X. Yes xinit forks and execs a user-writable script, but of course upon the exec to start the script cap_kill is lost, so the user can't abuse this. Since you pointed this out on your homepage, I have to assume you've decided you don't want to give cap_kill to xinit? No, since I'm using capabilities and I'm very happy with it, I grant cap_kill to xinit. For myself the problem is solved ... My other question is - do we want to maintain this signal restriction? So long as a privileged process isn't dumpable, is it any more dangerous for user hallyn to kill capability-raised process owned by hallyn than it is to kill a setuid process started by hallyn? If we decide no, then maybe we should remove cap_task_kill() as well as the cap_task_setnice(), cap_task_setioprio(), cap_task_setscheduler()? Or maybe i've just forgotten a compelling scenario... thanks, -serge ... but if some user decides to configure capabilities into the 2.6.24 kernel or just uses such a kernel and 1) is not granting cap_kill to xinit, and 2) starts X by issuing xinit on the console 3) ends after some time his X session, to come back to the console he will see a different behavior compared to 2.6.23 exiting his X session and (I think) believes to have a bug in the X package. Andrew Morton describes the problem here, too: http://lkml.org/lkml/2006/11/23/15 http://lkml.org/lkml/2006/11/23/19 Am I wrong in the assumption, but should one not accept an unchanged behavior with or without capabilities in the kernel regarding the behavior of applications, when he is not actually using (by not setting the xattr capability) capabilities with this application? If I'm wrong, maybe a warning or hint should be given that one has to grant cap_kill to xinit to come back to the console if the X session was started by xinit. Chris Chris Friedhoff [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc2 STD with s2disk fails to activate suspended system after loading - now 2.6.24-rc3
the patch on top of 2.6.24-rc3 fixed the problem. now I can succesfully s2disk. I tested it 5 times in a row, 2 from the console and 3 from within X thanks for fixing it, Chris On Tue, 20 Nov 2007 00:58:29 +0100 Rafael J. Wysocki [EMAIL PROTECTED] wrote: On Monday, 19 of November 2007, Chris Friedhoff wrote: dmesg output is added. increasing CONFIG_BLK_DEV_RAM_SIZE from to 131072 hasn't changed the non-functioning of 2.6.24-rc3 s2disk works with 2.6.23.8 ; I tested 4 cycles in a row, 2 from console and 2 from within X I've attached a patch to the bugzilla entry, please test it. Thanks, Rafael Chris Friedhoff [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc2 STD with s2disk fails to activate suspended system after loading - now 2.6.24-rc3
The patch http://bugzilla.kernel.org/attachment.cgi?id=13652action=view from Comment #16 of http://bugzilla.kernel.org/show_bug.cgi?id=9345 also works for me and enables successful s2disk cycles. Tested with 6 cycles, 3 from console and than 3 from within X. Thanks, Chris On Tue, 20 Nov 2007 00:58:29 +0100 Rafael J. Wysocki [EMAIL PROTECTED] wrote: On Monday, 19 of November 2007, Chris Friedhoff wrote: dmesg output is added. increasing CONFIG_BLK_DEV_RAM_SIZE from to 131072 hasn't changed the non-functioning of 2.6.24-rc3 s2disk works with 2.6.23.8 ; I tested 4 cycles in a row, 2 from console and 2 from within X I've attached a patch to the bugzilla entry, please test it. Thanks, Rafael Chris Friedhoff [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Posix file capabilities in 2.6.24rc2; now 2.6.24-rc3
On Tue, 20 Nov 2007 08:51:06 -0600 Serge E. Hallyn [EMAIL PROTECTED] wrote: Quoting Chris Friedhoff ([EMAIL PROTECTED]): On Mon, 19 Nov 2007 17:16:44 -0600 Serge E. Hallyn [EMAIL PROTECTED] wrote: Quoting Chris Friedhoff ([EMAIL PROTECTED]): Hello Serge, just to let you know: with 2.6.24-rc3 I have the same problem. Ok, so here is the flow. First off, using runlevel 5 on FC7, using 'log out' correctly brings you back to a new login prompt. Your problem is starting in runlevel 3, and typing 'xinit .xinitrc'; when you exit your wm, xinit is not allowed to kill X so you don't get back to your console. Yes, I'm booting in a runlevel without a session manager and starting my X session with xinit. (slackware: console-runlevel 3; sessionmanager-runlevel 4 ) First comment is, as you point out on your homepage, you could setfcaps -c cap_kill+p -e /usr/bin/xinit Then xinit is allowed to kill X. Yes xinit forks and execs a user-writable script, but of course upon the exec to start the script cap_kill is lost, so the user can't abuse this. Since you pointed this out on your homepage, I have to assume you've decided you don't want to give cap_kill to xinit? No, since I'm using capabilities and I'm very happy with it, I grant cap_kill to xinit. For myself the problem is solved ... My other question is - do we want to maintain this signal restriction? So long as a privileged process isn't dumpable, is it any more dangerous for user hallyn to kill capability-raised process owned by hallyn than it is to kill a setuid process started by hallyn? If we decide no, then maybe we should remove cap_task_kill() as well as the cap_task_setnice(), cap_task_setioprio(), cap_task_setscheduler()? Or maybe i've just forgotten a compelling scenario... thanks, -serge ... but if some user decides to configure capabilities into the 2.6.24 kernel or just uses such a kernel and 1) is not granting cap_kill to xinit, and 2) starts X by issuing xinit on the console 3) ends after some time his X session, to come back to the console he will see a different behavior compared to 2.6.23 exiting his X session and (I think) believes to have a bug in the X package. Andrew Morton describes the problem here, too: http://lkml.org/lkml/2006/11/23/15 http://lkml.org/lkml/2006/11/23/19 Am I wrong in the assumption, but should one not accept an unchanged behavior with or without capabilities in the kernel regarding the behavior of applications, when he is not actually using (by not setting the xattr capability) capabilities with this application? If I'm wrong, maybe a warning or hint should be given that one has to grant cap_kill to xinit to come back to the console if the X session was started by xinit. Thanks - yes, I see (I tend to get lost in my testruns). So we're back to trying to do the fix I was trying to do along with the SIGCONT fix a few weeks ago. The problem is that when you run a setuid binary, its pP and pE are fully raised. The following patch fixes it for me. Chris, does it fix your problem? Yes, this patch fixes it for me, too. Thanks, Chris Andrew, am I again confusing myself and doing something unsafe? thanks, -serge From d0b931776c0c424e583bf736d6a2498be4eccb98 Mon Sep 17 00:00:00 2001 From: Serge E. Hallyn [EMAIL PROTECTED] Date: Tue, 20 Nov 2007 08:47:35 + Subject: [PATCH 1/1] file capabilities: don't prevent signaling setuid root programs. When an unprivileged user runs a setuid root program in !SECURE_NOROOT mode, fP, fI, and fE are set full on, so pP' and pE' are full on. Then cap_task_kill() prevents the user from signaling the setuid root task. This is a change in behavior compared to when !CONFIG_SECURITY_FILE_CAPABILITIES. This patch introduces a special check into cap_task_kill() just to check whether a non-root user is signaling a setuid root program started by the same user. If so, then signal is allowed. This still leaves open the question of whether we want to go back to allowing users to signal binaries owned by them which had file capabilities set. Signed-off-by: Serge E. Hallyn [EMAIL PROTECTED] --- security/commoncap.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/security/commoncap.c b/security/commoncap.c index 302e8d0..d20d0a6 100644 --- a/security/commoncap.c +++ b/security/commoncap.c @@ -543,6 +543,9 @@ int cap_task_kill(struct task_struct *p, struct siginfo *info, if (capable(CAP_KILL)) return 0; + if (p-euid==0 p-uid==current-uid) + return 0; + return -EPERM; } #else -- 1.5.2.5 Chris Friedhoff [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo
Re: Posix file capabilities in 2.6.24rc2; now 2.6.24-rc3
On Tue, 20 Nov 2007 16:51:21 -0600 Serge E. Hallyn [EMAIL PROTECTED] wrote: Quoting Chris Friedhoff ([EMAIL PROTECTED]): On Tue, 20 Nov 2007 08:51:06 -0600 Serge E. Hallyn [EMAIL PROTECTED] wrote: Quoting Chris Friedhoff ([EMAIL PROTECTED]): On Mon, 19 Nov 2007 17:16:44 -0600 Serge E. Hallyn [EMAIL PROTECTED] wrote: Quoting Chris Friedhoff ([EMAIL PROTECTED]): Hello Serge, just to let you know: with 2.6.24-rc3 I have the same problem. Ok, so here is the flow. First off, using runlevel 5 on FC7, using 'log out' correctly brings you back to a new login prompt. Your problem is starting in runlevel 3, and typing 'xinit .xinitrc'; when you exit your wm, xinit is not allowed to kill X so you don't get back to your console. Yes, I'm booting in a runlevel without a session manager and starting my X session with xinit. (slackware: console-runlevel 3; sessionmanager-runlevel 4 ) First comment is, as you point out on your homepage, you could setfcaps -c cap_kill+p -e /usr/bin/xinit Then xinit is allowed to kill X. Yes xinit forks and execs a user-writable script, but of course upon the exec to start the script cap_kill is lost, so the user can't abuse this. Since you pointed this out on your homepage, I have to assume you've decided you don't want to give cap_kill to xinit? No, since I'm using capabilities and I'm very happy with it, I grant cap_kill to xinit. For myself the problem is solved ... My other question is - do we want to maintain this signal restriction? So long as a privileged process isn't dumpable, is it any more dangerous for user hallyn to kill capability-raised process owned by hallyn than it is to kill a setuid process started by hallyn? If we decide no, then maybe we should remove cap_task_kill() as well as the cap_task_setnice(), cap_task_setioprio(), cap_task_setscheduler()? Or maybe i've just forgotten a compelling scenario... thanks, -serge ... but if some user decides to configure capabilities into the 2.6.24 kernel or just uses such a kernel and 1) is not granting cap_kill to xinit, and 2) starts X by issuing xinit on the console 3) ends after some time his X session, to come back to the console he will see a different behavior compared to 2.6.23 exiting his X session and (I think) believes to have a bug in the X package. Andrew Morton describes the problem here, too: http://lkml.org/lkml/2006/11/23/15 http://lkml.org/lkml/2006/11/23/19 Am I wrong in the assumption, but should one not accept an unchanged behavior with or without capabilities in the kernel regarding the behavior of applications, when he is not actually using (by not setting the xattr capability) capabilities with this application? If I'm wrong, maybe a warning or hint should be given that one has to grant cap_kill to xinit to come back to the console if the X session was started by xinit. Thanks - yes, I see (I tend to get lost in my testruns). So we're back to trying to do the fix I was trying to do along with the SIGCONT fix a few weeks ago. The problem is that when you run a setuid binary, its pP and pE are fully raised. The following patch fixes it for me. Chris, does it fix your problem? Yes, this patch fixes it for me, too. Thanks, Chris Thanks for the valuable testing and bugreports, Chris. You're welcome! Chris If I don't hear any counter-arguments I'll post the patch in its own thread tomorrow. -serge Chris Friedhoff [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc2 STD with s2disk fails to activate suspended system after loading - now 2.6.24-rc3
dmesg output is added. increasing CONFIG_BLK_DEV_RAM_SIZE from to 131072 hasn't changed the non-functioning of 2.6.24-rc3 s2disk works with 2.6.23.8 ; I tested 4 cycles in a row, 2 from console and 2 from within X Chris On Mon, 19 Nov 2007 19:58:36 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote: > On Monday, 19 of November 2007, Chris Friedhoff wrote: > > Hallo Rafael, > > > > just to let you know: with 2.6.24-rc3 I have the same problem. > > Thanks. > > > On Sun, 11 Nov 2007 19:45:06 +0100 > > "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote: > > > > > On Saturday, 10 of November 2007, Chris Friedhoff wrote: > > > > please cc me, I'm not not subscribed to LKML > > > > > > > > Hello, > > > > > > > > with kernel 2.6.24-rc2 STD with s2disk suspends the system to disk, but > > > > when I start the system and the suspended systemimage is loaded, it > > > > fails to "activate" this suspended systemimage and continues after some > > > > time with following the normal boot sequence. > > Please add the dmesg output taken right after that as an attachment to the > bugzilla entry at http://bugzilla.kernel.org/show_bug.cgi?id=9345 > > Thanks, > Rafael Chris Friedhoff [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Posix file capabilities in 2.6.24rc2; now 2.6.24-rc3
Hello Serge, just to let you know: with 2.6.24-rc3 I have the same problem. Chris On Thu, 15 Nov 2007 23:02:27 +0100 Chris Friedhoff <[EMAIL PROTECTED]> wrote: > No, the patch doesn't fix the problem. > I still have the black screen with the cursor when I close the > xsession, only the windowmanager is closed. > consolemessage: > xinit: Operation not permitted (errno 1): Can't kill X server > kernel has capabilities, xinit has no caps granted. > > Chris > > > > I'm setting up a vm to play with this. Will look into it. > > > > Oh, looking at a few branches, I see that the patch for bug# 9247 > > (on bugzilla.kernel.org) isn't in 2.6.24-rc2 yet. Can you check > > whether the following patch fixes it? > > > > thanks, > > -serge > > > > >From 347faf5852644b91632813885784104f4cdb640a Mon Sep 17 00:00:00 2001 > > From: Serge E. Hallyn <[EMAIL PROTECTED]> > > Date: Wed, 14 Nov 2007 13:00:52 -0500 > > Subject: [PATCH 1/1] file capabilities: allow sigcont within session > > (v2.6.24-rc2) > > > > Allow sigcont to be sent to a process with greater capabilities > > if it is in the same session. Otherwise, a shell from which > > I've started a root shell and done 'suspend' can't be restarted > > by the parent shell. > > > > (this patch against v2.6.24-rc2) > > > > Signed-off-by: Serge E. Hallyn <[EMAIL PROTECTED]> > > --- > > security/commoncap.c |2 ++ > > 1 files changed, 2 insertions(+), 0 deletions(-) > > > > diff --git a/security/commoncap.c b/security/commoncap.c > > index bf67871..c9f6867 100644 > > --- a/security/commoncap.c > > +++ b/security/commoncap.c > > @@ -534,6 +534,8 @@ int cap_task_kill(struct task_struct *p, struct siginfo > > *info, > > * Used only by usb drivers? > > */ > > return 0; > > + if (sig == SIGCONT && (task_session_nr(current)==task_session_nr(p))) > > + return 0; > > if (cap_issubset(p->cap_permitted, current->cap_permitted)) > > return 0; > > if (capable(CAP_KILL)) > > -- > > 1.5.1.1.GIT > > > > Chris Friedhoff > [EMAIL PROTECTED] Chris Friedhoff [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc2 STD with s2disk fails to activate suspended system after loading - now 2.6.24-rc3
Hallo Rafael, just to let you know: with 2.6.24-rc3 I have the same problem. Chris On Sun, 11 Nov 2007 19:45:06 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote: > On Saturday, 10 of November 2007, Chris Friedhoff wrote: > > please cc me, I'm not not subscribed to LKML > > > > Hello, > > > > with kernel 2.6.24-rc2 STD with s2disk suspends the system to disk, but > > when I start the system and the suspended systemimage is loaded, it > > fails to "activate" this suspended systemimage and continues after some > > time with following the normal boot sequence. > > > > I can sucessfully STD the system with the following sequence > > echo platform > /sys/power/disk > > echo disk > /sys/power/state > > and when I start the laptop the suspended system is sucessfully > > restored. > > > > Both behaviors are reliable reproducable. > > Thanks for the report. > > > googling for >"Freezing of tasks failed" swapper< brought > > "Nigel Cunningham - PID namespaces break initrd+hibernate combination?" > > http://lkml.org/lkml/2007/11/4/140 > > Yes, this looks similarly. > > > dmesg output: > > <> > > RAMDISK: ext2 filesystem found at block 0 > > RAMDISK: Loading 2000KiB [1 disk] into ram disk... done. > > EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended > > VFS: Mounted root (ext2 filesystem). > > swsusp: Marking nosave pages: 0009f000 - 0010 > > swsusp: Basic memory bitmaps created > > Clocksource tsc unstable (delta = -128791628 ns) > > Syncing filesystems ... done. > > Freezing user space processes ... (elapsed 0.00 seconds) done. > > Freezing remaining freezable tasks ... > > Freezing of tasks failed after 20.00 seconds (1 tasks refusing to > > freeze): taskPC stack pid father > > swapper S c1835a88 0 1 0 > > 0046 c0118c80 c1835a88 0004 0001 c011e875 > > 0286 c01025a6 c1835b64 c1835a90 > > 0001 007b c1835a90 > > c0118c80 Call Trace: > > [] default_wake_function+0x0/0x10 > > [] do_wait+0x335/0xac0 > > [] kernel_thread+0x96/0xb0 > > [] default_wake_function+0x0/0x10 > > [] sys_wait4+0x31/0x40 > > [] initrd_load+0x1b3/0x3a0 > > [] prepare_namespace+0x98/0x1b0 > > [] sys_access+0x1f/0x30 > > [] kernel_init+0x166/0x260 > > [] ret_from_fork+0x6/0x1c > > [] kernel_init+0x0/0x260 > > [] kernel_init+0x0/0x260 > > [] kernel_thread_helper+0x7/0x18 > > === > > kthreadd S 038f 0 2 0 > > 0046 c0487790 038f c183ff1c c012d81b > > c012d7b0 c0104b8f > > > > Call Trace: > > [] kthreadd+0x6b/0xd0 > > [] kthreadd+0x0/0xd0 > > [] kernel_thread_helper+0x7/0x18 > > === > > ksoftirqd/0 S 0 3 2 > > 0046 fffc c0120f00 c0120f7a > > c012d782 c012d740 c0104b8f c183ff3c > > > > Call Trace: > > [] ksoftirqd+0x0/0x80 > > [] ksoftirqd+0x7a/0x80 > > [] kthread+0x42/0x70 > > [] kthread+0x0/0x70 > > [] kernel_thread_helper+0x7/0x18 > > > > <> > > Can you please attach your kernel configuration file to the bugzilla entry > at http://bugzilla.kernel.org/show_bug.cgi?id=9345 ? > > Thanks, > Rafael Chris Friedhoff [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Posix file capabilities in 2.6.24rc2; now 2.6.24-rc3
Hello Serge, just to let you know: with 2.6.24-rc3 I have the same problem. Chris On Thu, 15 Nov 2007 23:02:27 +0100 Chris Friedhoff [EMAIL PROTECTED] wrote: No, the patch doesn't fix the problem. I still have the black screen with the cursor when I close the xsession, only the windowmanager is closed. consolemessage: xinit: Operation not permitted (errno 1): Can't kill X server kernel has capabilities, xinit has no caps granted. Chris I'm setting up a vm to play with this. Will look into it. Oh, looking at a few branches, I see that the patch for bug# 9247 (on bugzilla.kernel.org) isn't in 2.6.24-rc2 yet. Can you check whether the following patch fixes it? thanks, -serge From 347faf5852644b91632813885784104f4cdb640a Mon Sep 17 00:00:00 2001 From: Serge E. Hallyn [EMAIL PROTECTED] Date: Wed, 14 Nov 2007 13:00:52 -0500 Subject: [PATCH 1/1] file capabilities: allow sigcont within session (v2.6.24-rc2) Allow sigcont to be sent to a process with greater capabilities if it is in the same session. Otherwise, a shell from which I've started a root shell and done 'suspend' can't be restarted by the parent shell. (this patch against v2.6.24-rc2) Signed-off-by: Serge E. Hallyn [EMAIL PROTECTED] --- security/commoncap.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/security/commoncap.c b/security/commoncap.c index bf67871..c9f6867 100644 --- a/security/commoncap.c +++ b/security/commoncap.c @@ -534,6 +534,8 @@ int cap_task_kill(struct task_struct *p, struct siginfo *info, * Used only by usb drivers? */ return 0; + if (sig == SIGCONT (task_session_nr(current)==task_session_nr(p))) + return 0; if (cap_issubset(p-cap_permitted, current-cap_permitted)) return 0; if (capable(CAP_KILL)) -- 1.5.1.1.GIT Chris Friedhoff [EMAIL PROTECTED] Chris Friedhoff [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc2 STD with s2disk fails to activate suspended system after loading - now 2.6.24-rc3
Hallo Rafael,
just to let you know: with 2.6.24-rc3 I have the same problem.
Chris
On Sun, 11 Nov 2007 19:45:06 +0100
Rafael J. Wysocki [EMAIL PROTECTED] wrote:
On Saturday, 10 of November 2007, Chris Friedhoff wrote:
please cc me, I'm not not subscribed to LKML
Hello,
with kernel 2.6.24-rc2 STD with s2disk suspends the system to disk, but
when I start the system and the suspended systemimage is loaded, it
fails to activate this suspended systemimage and continues after some
time with following the normal boot sequence.
I can sucessfully STD the system with the following sequence
echo platform /sys/power/disk
echo disk /sys/power/state
and when I start the laptop the suspended system is sucessfully
restored.
Both behaviors are reliable reproducable.
Thanks for the report.
googling for Freezing of tasks failed swapper brought
Nigel Cunningham - PID namespaces break initrd+hibernate combination?
http://lkml.org/lkml/2007/11/4/140
Yes, this looks similarly.
dmesg output:
snip
RAMDISK: ext2 filesystem found at block 0
RAMDISK: Loading 2000KiB [1 disk] into ram disk... done.
EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
VFS: Mounted root (ext2 filesystem).
swsusp: Marking nosave pages: 0009f000 - 0010
swsusp: Basic memory bitmaps created
Clocksource tsc unstable (delta = -128791628 ns)
Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.00 seconds) done.
Freezing remaining freezable tasks ...
Freezing of tasks failed after 20.00 seconds (1 tasks refusing to
freeze): taskPC stack pid father
swapper S c1835a88 0 1 0
0046 c0118c80 c1835a88 0004 0001 c011e875
0286 c01025a6 c1835b64 c1835a90
0001 007b c1835a90
c0118c80 Call Trace:
[c0118c80] default_wake_function+0x0/0x10
[c011e875] do_wait+0x335/0xac0
[c01025a6] kernel_thread+0x96/0xb0
[c0118c80] default_wake_function+0x0/0x10
[c011f031] sys_wait4+0x31/0x40
[c04b7a23] initrd_load+0x1b3/0x3a0
[c04b5108] prepare_namespace+0x98/0x1b0
[c016090f] sys_access+0x1f/0x30
[c04b47c6] kernel_init+0x166/0x260
[c0103f4a] ret_from_fork+0x6/0x1c
[c04b4660] kernel_init+0x0/0x260
[c04b4660] kernel_init+0x0/0x260
[c0104b8f] kernel_thread_helper+0x7/0x18
===
kthreadd S 038f 0 2 0
0046 c0487790 038f c183ff1c c012d81b
c012d7b0 c0104b8f
Call Trace:
[c012d81b] kthreadd+0x6b/0xd0
[c012d7b0] kthreadd+0x0/0xd0
[c0104b8f] kernel_thread_helper+0x7/0x18
===
ksoftirqd/0 S 0 3 2
0046 fffc c0120f00 c0120f7a
c012d782 c012d740 c0104b8f c183ff3c
Call Trace:
[c0120f00] ksoftirqd+0x0/0x80
[c0120f7a] ksoftirqd+0x7a/0x80
[c012d782] kthread+0x42/0x70
[c012d740] kthread+0x0/0x70
[c0104b8f] kernel_thread_helper+0x7/0x18
snip
Can you please attach your kernel configuration file to the bugzilla entry
at http://bugzilla.kernel.org/show_bug.cgi?id=9345 ?
Thanks,
Rafael
Chris Friedhoff
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc2 STD with s2disk fails to activate suspended system after loading - now 2.6.24-rc3
dmesg output is added. increasing CONFIG_BLK_DEV_RAM_SIZE from to 131072 hasn't changed the non-functioning of 2.6.24-rc3 s2disk works with 2.6.23.8 ; I tested 4 cycles in a row, 2 from console and 2 from within X Chris On Mon, 19 Nov 2007 19:58:36 +0100 Rafael J. Wysocki [EMAIL PROTECTED] wrote: On Monday, 19 of November 2007, Chris Friedhoff wrote: Hallo Rafael, just to let you know: with 2.6.24-rc3 I have the same problem. Thanks. On Sun, 11 Nov 2007 19:45:06 +0100 Rafael J. Wysocki [EMAIL PROTECTED] wrote: On Saturday, 10 of November 2007, Chris Friedhoff wrote: please cc me, I'm not not subscribed to LKML Hello, with kernel 2.6.24-rc2 STD with s2disk suspends the system to disk, but when I start the system and the suspended systemimage is loaded, it fails to activate this suspended systemimage and continues after some time with following the normal boot sequence. Please add the dmesg output taken right after that as an attachment to the bugzilla entry at http://bugzilla.kernel.org/show_bug.cgi?id=9345 Thanks, Rafael Chris Friedhoff [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Posix file capabilities in 2.6.24rc2
No, the patch doesn't fix the problem. I still have the black screen with the cursor when I close the xsession, only the windowmanager is closed. consolemessage: xinit: Operation not permitted (errno 1): Can't kill X server kernel has capabilities, xinit has no caps granted. Chris > I'm setting up a vm to play with this. Will look into it. > > Oh, looking at a few branches, I see that the patch for bug# 9247 > (on bugzilla.kernel.org) isn't in 2.6.24-rc2 yet. Can you check > whether the following patch fixes it? > > thanks, > -serge > > >From 347faf5852644b91632813885784104f4cdb640a Mon Sep 17 00:00:00 2001 > From: Serge E. Hallyn <[EMAIL PROTECTED]> > Date: Wed, 14 Nov 2007 13:00:52 -0500 > Subject: [PATCH 1/1] file capabilities: allow sigcont within session > (v2.6.24-rc2) > > Allow sigcont to be sent to a process with greater capabilities > if it is in the same session. Otherwise, a shell from which > I've started a root shell and done 'suspend' can't be restarted > by the parent shell. > > (this patch against v2.6.24-rc2) > > Signed-off-by: Serge E. Hallyn <[EMAIL PROTECTED]> > --- > security/commoncap.c |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/security/commoncap.c b/security/commoncap.c > index bf67871..c9f6867 100644 > --- a/security/commoncap.c > +++ b/security/commoncap.c > @@ -534,6 +534,8 @@ int cap_task_kill(struct task_struct *p, struct siginfo > *info, >* Used only by usb drivers? >*/ > return 0; > + if (sig == SIGCONT && (task_session_nr(current)==task_session_nr(p))) > + return 0; > if (cap_issubset(p->cap_permitted, current->cap_permitted)) > return 0; > if (capable(CAP_KILL)) > -- > 1.5.1.1.GIT Chris Friedhoff [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Posix file capabilities in 2.6.24rc2
No, the patch doesn't fix the problem. I still have the black screen with the cursor when I close the xsession, only the windowmanager is closed. consolemessage: xinit: Operation not permitted (errno 1): Can't kill X server kernel has capabilities, xinit has no caps granted. Chris I'm setting up a vm to play with this. Will look into it. Oh, looking at a few branches, I see that the patch for bug# 9247 (on bugzilla.kernel.org) isn't in 2.6.24-rc2 yet. Can you check whether the following patch fixes it? thanks, -serge From 347faf5852644b91632813885784104f4cdb640a Mon Sep 17 00:00:00 2001 From: Serge E. Hallyn [EMAIL PROTECTED] Date: Wed, 14 Nov 2007 13:00:52 -0500 Subject: [PATCH 1/1] file capabilities: allow sigcont within session (v2.6.24-rc2) Allow sigcont to be sent to a process with greater capabilities if it is in the same session. Otherwise, a shell from which I've started a root shell and done 'suspend' can't be restarted by the parent shell. (this patch against v2.6.24-rc2) Signed-off-by: Serge E. Hallyn [EMAIL PROTECTED] --- security/commoncap.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/security/commoncap.c b/security/commoncap.c index bf67871..c9f6867 100644 --- a/security/commoncap.c +++ b/security/commoncap.c @@ -534,6 +534,8 @@ int cap_task_kill(struct task_struct *p, struct siginfo *info, * Used only by usb drivers? */ return 0; + if (sig == SIGCONT (task_session_nr(current)==task_session_nr(p))) + return 0; if (cap_issubset(p-cap_permitted, current-cap_permitted)) return 0; if (capable(CAP_KILL)) -- 1.5.1.1.GIT Chris Friedhoff [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Posix file capabilities in 2.6.24rc2
Hello Serge, I wanted only to express what I observed. A "yes it should" confirms its ok. And yes, I haven't looked into the patches and the name and commentary of file-capabilities-clear-fcaps-on-inode-change.patch explains this already. I'm preparing to update my page http://www.friedhoff.org/fscaps.html for 2.6.24, and I also want to explain what one has to take into account or be beware off. If I stumble about this, I think others will also (imho). I have written a script to change suid binaries and servers, automating the examples I give on the webpage. In the sequence of commands I was setting fscaps and than chown the binary. Now with the aforementioned patch the fscaps are removed when I chown and the script wasn't working anymore. My point is not my script, it's being surprised and being a bit at a loss. Documenting this helps to clarify things and users to adopt this feature. The matter with "xinit: Operation not permitted..." happens, when I (unprivileged user) close a from a console started X session. Similar to Andrew Morton'S http://lkml.org/lkml/2006/11/23/15 . The 2.6.24-rc2 kernel has capabilties enabled but /usr/bin/xinit has no capabilities set. It remains the black screen with a cursor, the windowmanager is closed. Is this known? Is this a problem? Does anyone else observes this? As far as I understand, I dont have to grant / to use capabilities even when the kernel has capabilities enabled. Chris On Tue, 13 Nov 2007 17:53:18 -0600 "Serge E. Hallyn" <[EMAIL PROTECTED]> wrote: > Quoting Chris Friedhoff ([EMAIL PROTECTED]): > > Hello, > > > > everything works as expected, but ... > > > > closing X and no capabilities set for xinit does shutdown only the > > windowmanager and not the X server (Xorg server 1.4) > > Consolemessage is: > > xinit: Operation not permitted (errno 1): Can't kill X server > > > > > > the xattr capability is removed, when the file is chown'ed. > > Hi Chris, > > yes on chown the capability is removed. I'm not quite sure what > you're asking? Is your setup depending on being able to chown > while keeping file capabilities? Can you give some more details? > > thanks, > -serge Chris Friedhoff [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Posix file capabilities in 2.6.24rc2
Hello Serge, I wanted only to express what I observed. A yes it should confirms its ok. And yes, I haven't looked into the patches and the name and commentary of file-capabilities-clear-fcaps-on-inode-change.patch explains this already. I'm preparing to update my page http://www.friedhoff.org/fscaps.html for 2.6.24, and I also want to explain what one has to take into account or be beware off. If I stumble about this, I think others will also (imho). I have written a script to change suid binaries and servers, automating the examples I give on the webpage. In the sequence of commands I was setting fscaps and than chown the binary. Now with the aforementioned patch the fscaps are removed when I chown and the script wasn't working anymore. My point is not my script, it's being surprised and being a bit at a loss. Documenting this helps to clarify things and users to adopt this feature. The matter with xinit: Operation not permitted... happens, when I (unprivileged user) close a from a console started X session. Similar to Andrew Morton'S http://lkml.org/lkml/2006/11/23/15 . The 2.6.24-rc2 kernel has capabilties enabled but /usr/bin/xinit has no capabilities set. It remains the black screen with a cursor, the windowmanager is closed. Is this known? Is this a problem? Does anyone else observes this? As far as I understand, I dont have to grant / to use capabilities even when the kernel has capabilities enabled. Chris On Tue, 13 Nov 2007 17:53:18 -0600 Serge E. Hallyn [EMAIL PROTECTED] wrote: Quoting Chris Friedhoff ([EMAIL PROTECTED]): Hello, everything works as expected, but ... closing X and no capabilities set for xinit does shutdown only the windowmanager and not the X server (Xorg server 1.4) Consolemessage is: xinit: Operation not permitted (errno 1): Can't kill X server the xattr capability is removed, when the file is chown'ed. Hi Chris, yes on chown the capability is removed. I'm not quite sure what you're asking? Is your setup depending on being able to chown while keeping file capabilities? Can you give some more details? thanks, -serge Chris Friedhoff [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Posix file capabilities in 2.6.24rc2
Hello, everything works as expected, but ... closing X and no capabilities set for xinit does shutdown only the windowmanager and not the X server (Xorg server 1.4) Consolemessage is: xinit: Operation not permitted (errno 1): Can't kill X server the xattr capability is removed, when the file is chown'ed. Chris Chris Friedhoff [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Posix file capabilities in 2.6.24rc2
Hello, everything works as expected, but ... closing X and no capabilities set for xinit does shutdown only the windowmanager and not the X server (Xorg server 1.4) Consolemessage is: xinit: Operation not permitted (errno 1): Can't kill X server the xattr capability is removed, when the file is chown'ed. Chris Chris Friedhoff [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc2 STD with s2disk fails to activate suspended system after loading
kernel config attached to comment#2 for bugreport 9345 s2disk comes from suspend-0.7 package Thanks, Chris On Sun, 11 Nov 2007 19:45:06 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote: > On Saturday, 10 of November 2007, Chris Friedhoff wrote: > > please cc me, I'm not not subscribed to LKML > > > > Hello, > > > > with kernel 2.6.24-rc2 STD with s2disk suspends the system to disk, but > > when I start the system and the suspended systemimage is loaded, it > > fails to "activate" this suspended systemimage and continues after some > > time with following the normal boot sequence. > > > > I can sucessfully STD the system with the following sequence > > echo platform > /sys/power/disk > > echo disk > /sys/power/state > > and when I start the laptop the suspended system is sucessfully > > restored. > > > > Both behaviors are reliable reproducable. > > Thanks for the report. > > > googling for >"Freezing of tasks failed" swapper< brought > > "Nigel Cunningham - PID namespaces break initrd+hibernate combination?" > > http://lkml.org/lkml/2007/11/4/140 > > Yes, this looks similarly. > > > dmesg output: > > <> > > RAMDISK: ext2 filesystem found at block 0 > > RAMDISK: Loading 2000KiB [1 disk] into ram disk... done. > > EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended > > VFS: Mounted root (ext2 filesystem). > > swsusp: Marking nosave pages: 0009f000 - 0010 > > swsusp: Basic memory bitmaps created > > Clocksource tsc unstable (delta = -128791628 ns) > > Syncing filesystems ... done. > > Freezing user space processes ... (elapsed 0.00 seconds) done. > > Freezing remaining freezable tasks ... > > Freezing of tasks failed after 20.00 seconds (1 tasks refusing to > > freeze): taskPC stack pid father > > swapper S c1835a88 0 1 0 > > 0046 c0118c80 c1835a88 0004 0001 c011e875 > > 0286 c01025a6 c1835b64 c1835a90 > > 0001 007b c1835a90 > > c0118c80 Call Trace: > > [] default_wake_function+0x0/0x10 > > [] do_wait+0x335/0xac0 > > [] kernel_thread+0x96/0xb0 > > [] default_wake_function+0x0/0x10 > > [] sys_wait4+0x31/0x40 > > [] initrd_load+0x1b3/0x3a0 > > [] prepare_namespace+0x98/0x1b0 > > [] sys_access+0x1f/0x30 > > [] kernel_init+0x166/0x260 > > [] ret_from_fork+0x6/0x1c > > [] kernel_init+0x0/0x260 > > [] kernel_init+0x0/0x260 > > [] kernel_thread_helper+0x7/0x18 > > === > > kthreadd S 038f 0 2 0 > > 0046 c0487790 038f c183ff1c c012d81b > > c012d7b0 c0104b8f > > > > Call Trace: > > [] kthreadd+0x6b/0xd0 > > [] kthreadd+0x0/0xd0 > > [] kernel_thread_helper+0x7/0x18 > > === > > ksoftirqd/0 S 0 3 2 > > 0046 fffc c0120f00 c0120f7a > > c012d782 c012d740 c0104b8f c183ff3c > > > > Call Trace: > > [] ksoftirqd+0x0/0x80 > > [] ksoftirqd+0x7a/0x80 > > [] kthread+0x42/0x70 > > [] kthread+0x0/0x70 > > [] kernel_thread_helper+0x7/0x18 > > > > <> > > Can you please attach your kernel configuration file to the bugzilla entry > at http://bugzilla.kernel.org/show_bug.cgi?id=9345 ? > > Thanks, > Rafael Chris Friedhoff [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc2 STD with s2disk fails to activate suspended system after loading
kernel config attached to comment#2 for bugreport 9345
s2disk comes from suspend-0.7 package
Thanks,
Chris
On Sun, 11 Nov 2007 19:45:06 +0100
Rafael J. Wysocki [EMAIL PROTECTED] wrote:
On Saturday, 10 of November 2007, Chris Friedhoff wrote:
please cc me, I'm not not subscribed to LKML
Hello,
with kernel 2.6.24-rc2 STD with s2disk suspends the system to disk, but
when I start the system and the suspended systemimage is loaded, it
fails to activate this suspended systemimage and continues after some
time with following the normal boot sequence.
I can sucessfully STD the system with the following sequence
echo platform /sys/power/disk
echo disk /sys/power/state
and when I start the laptop the suspended system is sucessfully
restored.
Both behaviors are reliable reproducable.
Thanks for the report.
googling for Freezing of tasks failed swapper brought
Nigel Cunningham - PID namespaces break initrd+hibernate combination?
http://lkml.org/lkml/2007/11/4/140
Yes, this looks similarly.
dmesg output:
snip
RAMDISK: ext2 filesystem found at block 0
RAMDISK: Loading 2000KiB [1 disk] into ram disk... done.
EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
VFS: Mounted root (ext2 filesystem).
swsusp: Marking nosave pages: 0009f000 - 0010
swsusp: Basic memory bitmaps created
Clocksource tsc unstable (delta = -128791628 ns)
Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.00 seconds) done.
Freezing remaining freezable tasks ...
Freezing of tasks failed after 20.00 seconds (1 tasks refusing to
freeze): taskPC stack pid father
swapper S c1835a88 0 1 0
0046 c0118c80 c1835a88 0004 0001 c011e875
0286 c01025a6 c1835b64 c1835a90
0001 007b c1835a90
c0118c80 Call Trace:
[c0118c80] default_wake_function+0x0/0x10
[c011e875] do_wait+0x335/0xac0
[c01025a6] kernel_thread+0x96/0xb0
[c0118c80] default_wake_function+0x0/0x10
[c011f031] sys_wait4+0x31/0x40
[c04b7a23] initrd_load+0x1b3/0x3a0
[c04b5108] prepare_namespace+0x98/0x1b0
[c016090f] sys_access+0x1f/0x30
[c04b47c6] kernel_init+0x166/0x260
[c0103f4a] ret_from_fork+0x6/0x1c
[c04b4660] kernel_init+0x0/0x260
[c04b4660] kernel_init+0x0/0x260
[c0104b8f] kernel_thread_helper+0x7/0x18
===
kthreadd S 038f 0 2 0
0046 c0487790 038f c183ff1c c012d81b
c012d7b0 c0104b8f
Call Trace:
[c012d81b] kthreadd+0x6b/0xd0
[c012d7b0] kthreadd+0x0/0xd0
[c0104b8f] kernel_thread_helper+0x7/0x18
===
ksoftirqd/0 S 0 3 2
0046 fffc c0120f00 c0120f7a
c012d782 c012d740 c0104b8f c183ff3c
Call Trace:
[c0120f00] ksoftirqd+0x0/0x80
[c0120f7a] ksoftirqd+0x7a/0x80
[c012d782] kthread+0x42/0x70
[c012d740] kthread+0x0/0x70
[c0104b8f] kernel_thread_helper+0x7/0x18
snip
Can you please attach your kernel configuration file to the bugzilla entry
at http://bugzilla.kernel.org/show_bug.cgi?id=9345 ?
Thanks,
Rafael
Chris Friedhoff
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
2.6.24-rc2 STD with s2disk fails to activate suspended system after loading
please cc me, I'm not not subscribed to LKML
Hello,
with kernel 2.6.24-rc2 STD with s2disk suspends the system to disk, but
when I start the system and the suspended systemimage is loaded, it
fails to "activate" this suspended systemimage and continues after some
time with following the normal boot sequence.
I can sucessfully STD the system with the following sequence
echo platform > /sys/power/disk
echo disk > /sys/power/state
and when I start the laptop the suspended system is sucessfully
restored.
Both behaviors are reliable reproducable.
googling for >"Freezing of tasks failed" swapper< brought
"Nigel Cunningham - PID namespaces break initrd+hibernate combination?"
http://lkml.org/lkml/2007/11/4/140
dmesg output:
<>
RAMDISK: ext2 filesystem found at block 0
RAMDISK: Loading 2000KiB [1 disk] into ram disk... done.
EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
VFS: Mounted root (ext2 filesystem).
swsusp: Marking nosave pages: 0009f000 - 0010
swsusp: Basic memory bitmaps created
Clocksource tsc unstable (delta = -128791628 ns)
Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.00 seconds) done.
Freezing remaining freezable tasks ...
Freezing of tasks failed after 20.00 seconds (1 tasks refusing to
freeze): taskPC stack pid father
swapper S c1835a88 0 1 0
0046 c0118c80 c1835a88 0004 0001 c011e875
0286 c01025a6 c1835b64 c1835a90
0001 007b c1835a90
c0118c80 Call Trace:
[] default_wake_function+0x0/0x10
[] do_wait+0x335/0xac0
[] kernel_thread+0x96/0xb0
[] default_wake_function+0x0/0x10
[] sys_wait4+0x31/0x40
[] initrd_load+0x1b3/0x3a0
[] prepare_namespace+0x98/0x1b0
[] sys_access+0x1f/0x30
[] kernel_init+0x166/0x260
[] ret_from_fork+0x6/0x1c
[] kernel_init+0x0/0x260
[] kernel_init+0x0/0x260
[] kernel_thread_helper+0x7/0x18
===
kthreadd S 038f 0 2 0
0046 c0487790 038f c183ff1c c012d81b
c012d7b0 c0104b8f
Call Trace:
[] kthreadd+0x6b/0xd0
[] kthreadd+0x0/0xd0
[] kernel_thread_helper+0x7/0x18
===
ksoftirqd/0 S 0 3 2
0046 fffc c0120f00 c0120f7a
c012d782 c012d740 c0104b8f c183ff3c
Call Trace:
[] ksoftirqd+0x0/0x80
[] ksoftirqd+0x7a/0x80
[] kthread+0x42/0x70
[] kthread+0x0/0x70
[] kernel_thread_helper+0x7/0x18
<>
Chris Friedhoff
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
2.6.24-rc2 STD with s2disk fails to activate suspended system after loading
please cc me, I'm not not subscribed to LKML
Hello,
with kernel 2.6.24-rc2 STD with s2disk suspends the system to disk, but
when I start the system and the suspended systemimage is loaded, it
fails to activate this suspended systemimage and continues after some
time with following the normal boot sequence.
I can sucessfully STD the system with the following sequence
echo platform /sys/power/disk
echo disk /sys/power/state
and when I start the laptop the suspended system is sucessfully
restored.
Both behaviors are reliable reproducable.
googling for Freezing of tasks failed swapper brought
Nigel Cunningham - PID namespaces break initrd+hibernate combination?
http://lkml.org/lkml/2007/11/4/140
dmesg output:
snip
RAMDISK: ext2 filesystem found at block 0
RAMDISK: Loading 2000KiB [1 disk] into ram disk... done.
EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
VFS: Mounted root (ext2 filesystem).
swsusp: Marking nosave pages: 0009f000 - 0010
swsusp: Basic memory bitmaps created
Clocksource tsc unstable (delta = -128791628 ns)
Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.00 seconds) done.
Freezing remaining freezable tasks ...
Freezing of tasks failed after 20.00 seconds (1 tasks refusing to
freeze): taskPC stack pid father
swapper S c1835a88 0 1 0
0046 c0118c80 c1835a88 0004 0001 c011e875
0286 c01025a6 c1835b64 c1835a90
0001 007b c1835a90
c0118c80 Call Trace:
[c0118c80] default_wake_function+0x0/0x10
[c011e875] do_wait+0x335/0xac0
[c01025a6] kernel_thread+0x96/0xb0
[c0118c80] default_wake_function+0x0/0x10
[c011f031] sys_wait4+0x31/0x40
[c04b7a23] initrd_load+0x1b3/0x3a0
[c04b5108] prepare_namespace+0x98/0x1b0
[c016090f] sys_access+0x1f/0x30
[c04b47c6] kernel_init+0x166/0x260
[c0103f4a] ret_from_fork+0x6/0x1c
[c04b4660] kernel_init+0x0/0x260
[c04b4660] kernel_init+0x0/0x260
[c0104b8f] kernel_thread_helper+0x7/0x18
===
kthreadd S 038f 0 2 0
0046 c0487790 038f c183ff1c c012d81b
c012d7b0 c0104b8f
Call Trace:
[c012d81b] kthreadd+0x6b/0xd0
[c012d7b0] kthreadd+0x0/0xd0
[c0104b8f] kernel_thread_helper+0x7/0x18
===
ksoftirqd/0 S 0 3 2
0046 fffc c0120f00 c0120f7a
c012d782 c012d740 c0104b8f c183ff3c
Call Trace:
[c0120f00] ksoftirqd+0x0/0x80
[c0120f7a] ksoftirqd+0x7a/0x80
[c012d782] kthread+0x42/0x70
[c012d740] kthread+0x0/0x70
[c0104b8f] kernel_thread_helper+0x7/0x18
snip
Chris Friedhoff
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Implement file posix capabilities
I use this patch with 2.6.18.3. patching: ok configuring: ok compiling: ok installing: ok running: ok tested with httpd, smbd, nmbd, named, cupsd, ping, traceroute, modprobe, traceroute, ntpdate, xinit, killall, eject, dhcpd, route, qemu: ok I use this patch as documented: http://www.friedhoff.org/fscaps.html I also tested the patched kernel with "CONFIG_SECURITY_FS_CAPABILITIES is not set" and xinit kills X perfectly, when the GUI is stopped. Any other tests that might be helpful? The webpage is updated. Chris On Mon, 27 Nov 2006 11:07:40 -0600 "Serge E. Hallyn" <[EMAIL PROTECTED]> wrote: > From: Serge E. Hallyn <[EMAIL PROTECTED]> > Subject: [PATCH 1/1] Implement file posix capabilities > > Implement file posix capabilities. This allows programs to be given a > subset of root's powers regardless of who runs them, without having to use > setuid and giving the binary all of root's powers. > > This version works with Kaigai Kohei's userspace tools, found at > http://www.kaigai.gr.jp/index.php. For more information on how to use this > patch, Chris Friedhoff has posted a nice page at > http://www.friedhoff.org/fscaps.html. > > Changelog: > Nov 27: > Incorporate fixes from Andrew Morton > (security-introduce-file-caps-tweaks and > security-introduce-file-caps-warning-fix) > Fix Kconfig dependency. > Fix change signaling behavior when file caps are not compiled in. - snip - Chris Friedhoff [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Implement file posix capabilities
I use this patch with 2.6.18.3. patching: ok configuring: ok compiling: ok installing: ok running: ok tested with httpd, smbd, nmbd, named, cupsd, ping, traceroute, modprobe, traceroute, ntpdate, xinit, killall, eject, dhcpd, route, qemu: ok I use this patch as documented: http://www.friedhoff.org/fscaps.html I also tested the patched kernel with CONFIG_SECURITY_FS_CAPABILITIES is not set and xinit kills X perfectly, when the GUI is stopped. Any other tests that might be helpful? The webpage is updated. Chris On Mon, 27 Nov 2006 11:07:40 -0600 Serge E. Hallyn [EMAIL PROTECTED] wrote: From: Serge E. Hallyn [EMAIL PROTECTED] Subject: [PATCH 1/1] Implement file posix capabilities Implement file posix capabilities. This allows programs to be given a subset of root's powers regardless of who runs them, without having to use setuid and giving the binary all of root's powers. This version works with Kaigai Kohei's userspace tools, found at http://www.kaigai.gr.jp/index.php. For more information on how to use this patch, Chris Friedhoff has posted a nice page at http://www.friedhoff.org/fscaps.html. Changelog: Nov 27: Incorporate fixes from Andrew Morton (security-introduce-file-caps-tweaks and security-introduce-file-caps-warning-fix) Fix Kconfig dependency. Fix change signaling behavior when file caps are not compiled in. - snip - Chris Friedhoff [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: file caps: permit unsafe signaling when CONFIG_FS_CAPS=n
Serge, may I ask you to send a new complete patch with Andrew Mortons additions and this change and a new changelog entry. Thanks Chris On Fri, 24 Nov 2006 12:17:42 -0600 "Serge E. Hallyn" <[EMAIL PROTECTED]> wrote: > Quoting Serge E. Hallyn ([EMAIL PROTECTED]): > > Ok, the following patch restores the CONFIG_FS_CAPS=n signaling > > behavior, but I'm having a config problem. When > > CONFIG_SECURITY_CAPABILITIES=n, and I toggle > > CONFIG_SECURITY_FS_CAPABILITIES between y and n, security/commoncap.o > > does not recompile. However since capabilities are now the default > > security module, commoncap.o is in fact included in the kernel build, > > and therefore should be recompiled. > > > > Looking into why, but maybe someone knows offhand what would be going > > wrong? > > Uh, never mind. It does the right thing. CONFIG_SECURITY=n means we > use capabilities, but CONFIG_SECURITY=y and CONFIG_SECURITY_CAPABILITIES=n > means we use dummy. The following patch fixes the Kconfig accordingly. > > From: Serge E. Hallyn <[EMAIL PROTECTED]> > Subject: [PATCH 1/1] file caps: don't show FILE_CAPABILITIES option when not > relevant > > FILE_CAPABILITIES are relevant when CONFIG_SECURITY=n, but not when > CONFIG_SECURITY=y && CONFIG_SECURITY_CAPABILITIES=n. So make > CONFIG_SECURITY_FS_CAPABILITIES depend on the right conditions. > > Signed-off-by: Serge E. Hallyn <[EMAIL PROTECTED]> > --- > security/Kconfig |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/security/Kconfig b/security/Kconfig > index 6c9d69e..1b47f01 100644 > --- a/security/Kconfig > +++ b/security/Kconfig > @@ -82,6 +82,7 @@ config SECURITY_CAPABILITIES > > config SECURITY_FS_CAPABILITIES > bool "File POSIX Capabilities" > + depends on SECURITY=n || SECURITY_CAPABILITIES=y > default n > help > This enables filesystem capabilities, allowing you to give > -- > 1.4.1 > Chris Friedhoff [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: file caps: permit unsafe signaling when CONFIG_FS_CAPS=n
Serge, may I ask you to send a new complete patch with Andrew Mortons additions and this change and a new changelog entry. Thanks Chris On Fri, 24 Nov 2006 12:17:42 -0600 Serge E. Hallyn [EMAIL PROTECTED] wrote: Quoting Serge E. Hallyn ([EMAIL PROTECTED]): Ok, the following patch restores the CONFIG_FS_CAPS=n signaling behavior, but I'm having a config problem. When CONFIG_SECURITY_CAPABILITIES=n, and I toggle CONFIG_SECURITY_FS_CAPABILITIES between y and n, security/commoncap.o does not recompile. However since capabilities are now the default security module, commoncap.o is in fact included in the kernel build, and therefore should be recompiled. Looking into why, but maybe someone knows offhand what would be going wrong? Uh, never mind. It does the right thing. CONFIG_SECURITY=n means we use capabilities, but CONFIG_SECURITY=y and CONFIG_SECURITY_CAPABILITIES=n means we use dummy. The following patch fixes the Kconfig accordingly. From: Serge E. Hallyn [EMAIL PROTECTED] Subject: [PATCH 1/1] file caps: don't show FILE_CAPABILITIES option when not relevant FILE_CAPABILITIES are relevant when CONFIG_SECURITY=n, but not when CONFIG_SECURITY=y CONFIG_SECURITY_CAPABILITIES=n. So make CONFIG_SECURITY_FS_CAPABILITIES depend on the right conditions. Signed-off-by: Serge E. Hallyn [EMAIL PROTECTED] --- security/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/security/Kconfig b/security/Kconfig index 6c9d69e..1b47f01 100644 --- a/security/Kconfig +++ b/security/Kconfig @@ -82,6 +82,7 @@ config SECURITY_CAPABILITIES config SECURITY_FS_CAPABILITIES bool File POSIX Capabilities + depends on SECURITY=n || SECURITY_CAPABILITIES=y default n help This enables filesystem capabilities, allowing you to give -- 1.4.1 Chris Friedhoff [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] security: introduce fs caps
compiling fscaps-1.0-kg.src.rpm just gives the same result /bin/ping: Invalid argument (errno=22) trace output attached Chris Chris Friedhoff [EMAIL PROTECTED] strace-ping-sles10-b.gz Description: Binary data
Re: [PATCH 1/1] security: introduce fs caps
> Good quesion. My gentoo ia32 machine uses libcap.so.1.10. Probably a FAQ, > but is 1.92 actually older than 1.10? looking at these locations, yes http://www.me.kernel.org/pub/linux/libs/security/linux-privs/old/kernel-2.3/ http://ftp.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.4/ > | Kaigai also provides a srpm package to compile. > | VFS Capability Support -> fscaps version 1.0 [SRPM] > | (http://www.kaigai.gr.jp/pub/fscaps-1.0-kg.src.rpm) > > I'll try that next. I installed sles10 in qemu on my pentium-m laptop, compiled a kernel with fscap support and installed fscaps-1.0-kg.i386.rpm and got "Invalid argument (errno=22)" error. trace output is attached # id uid=0(root) gid=0(root) groups=0(root) # uname -a Linux sles10 2.6.19-rc3-fscaps-a #2 Fri Nov 17 09:17:40 CET 2006 i686 i686 i386 GNU/Linux # rpm -q fscaps fscaps-1.0-kg # zgrep -i capa /proc/config.gz CONFIG_SECURITY_FS_CAPABILITIES=y # setfcaps cap_net_raw=ep /bin/ping /bin/ping: Invalid argument (errno=22) # setfcaps cap_sys_module=ep /sbin/modprobe /sbin/modprobe: Invalid argument (errno=22) # ls -l /lib/libcap.so* lrwxrwxrwx 1 root root11 Nov 17 09:51 /lib/libcap.so -> libcap.so.1 lrwxrwxrwx 1 root root14 Nov 16 11:57 /lib/libcap.so.1 -> libcap.so.1.92 -rwxr-xr-x 1 root root 10456 Jun 16 15:14 /lib/libcap.so.1.92 Chris Friedhoff [EMAIL PROTECTED] strace-ping-sles10.gz Description: Binary data
Re: [PATCH 1/1] security: introduce fs caps
Good quesion. My gentoo ia32 machine uses libcap.so.1.10. Probably a FAQ, but is 1.92 actually older than 1.10? looking at these locations, yes http://www.me.kernel.org/pub/linux/libs/security/linux-privs/old/kernel-2.3/ http://ftp.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.4/ | Kaigai also provides a srpm package to compile. | VFS Capability Support - fscaps version 1.0 [SRPM] | (http://www.kaigai.gr.jp/pub/fscaps-1.0-kg.src.rpm) I'll try that next. I installed sles10 in qemu on my pentium-m laptop, compiled a kernel with fscap support and installed fscaps-1.0-kg.i386.rpm and got Invalid argument (errno=22) error. trace output is attached # id uid=0(root) gid=0(root) groups=0(root) # uname -a Linux sles10 2.6.19-rc3-fscaps-a #2 Fri Nov 17 09:17:40 CET 2006 i686 i686 i386 GNU/Linux # rpm -q fscaps fscaps-1.0-kg # zgrep -i capa /proc/config.gz CONFIG_SECURITY_FS_CAPABILITIES=y # setfcaps cap_net_raw=ep /bin/ping /bin/ping: Invalid argument (errno=22) # setfcaps cap_sys_module=ep /sbin/modprobe /sbin/modprobe: Invalid argument (errno=22) # ls -l /lib/libcap.so* lrwxrwxrwx 1 root root11 Nov 17 09:51 /lib/libcap.so - libcap.so.1 lrwxrwxrwx 1 root root14 Nov 16 11:57 /lib/libcap.so.1 - libcap.so.1.92 -rwxr-xr-x 1 root root 10456 Jun 16 15:14 /lib/libcap.so.1.92 Chris Friedhoff [EMAIL PROTECTED] strace-ping-sles10.gz Description: Binary data
Re: [PATCH 1/1] security: introduce fs caps
compiling fscaps-1.0-kg.src.rpm just gives the same result /bin/ping: Invalid argument (errno=22) trace output attached Chris Chris Friedhoff [EMAIL PROTECTED] strace-ping-sles10-b.gz Description: Binary data
