lkml.org 
[lkml]   [2009]   [Mar]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: VFS, NFS security bug? Should CAP_MKNOD and CAP_LINUX_IMMUTABLE be added to CAP_FS_MASK?
    Quoting J. Bruce Fields (bfields@fieldses.org):
    > On Mon, Mar 16, 2009 at 12:04:33PM -0500, Serge E. Hallyn wrote:
    > > Quoting J. Bruce Fields (bfields@fieldses.org):
    > > > If filesystem permissions similarly never affected the ability to create
    > > > device nodes, that might also be an argument against including
    > > > CAP_MKNOD, but it would be interesting to know the pre-capabilities
    > > > behavior of a uid 0 process with fsuid non-0.
    > >
    > > The sentiment rings true, but again since before capabilities, privilege
    > > was fully tied to the userid, the question doesn't make sense. Either
    > > you had uid 0 and could mknod, or you didn't and couldn't. And that is
    > > the behavior which we unfortunately have to emulate when
    > > !issecure(SECURE_NOROOT|SECURE_NOSUIDFIXUP).
    >
    > The historical behavior of setfsuid() is still interesting, though.
    > >From a quick glance at Debian's code for the (long-neglected) userspace
    > nfsd server, it looks like it depends on setfsuid() and the kernel to
    > enforce permissions for operations (including mknod). Might be

    Sorry, do you mean that it would expect setfsuid(0) to allow a task to
    do mknod, and setfsuid(500) to disable it?

    Actually I guess for mknod, that is the question we can answer with the
    a 2.1.x tree: which uid did mknod check?

    Ah, answer is... fsuid!

    > interesting to confirm whether it has the same problem, and if so,
    > whether that was a problem introduced with some capability changes or
    > whether it always existed.
    >
    > --b.


    \
     
     \ /
      Last update: 2009-03-17 00:03    [from the cache]
    ©2003-2011 Jasper Spaans