lkml.org 
[lkml]   [2007]   [Nov]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Posix file capabilities in 2.6.24rc2; now 2.6.24-rc3
    On Mon, 19 Nov 2007 17:16:44 -0600
    "Serge E. Hallyn" <sergeh@us.ibm.com> wrote:

    > Quoting Chris Friedhoff (chris@friedhoff.org):
    > > 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
    chris@friedhoff.org
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-11-20 10:49    [W:3.788 / U:0.540 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site