lkml.org 
[lkml]   [2009]   [Nov]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH v2 resend] vfs: new O_NODE open flag
    From
    Date
    On Thu, 5 Nov 2009, Alan Cox wrote:
    > The examples on the list are not entirely theoretical but based on
    > accepted and normal behaviour for application programming and Unix
    > security models -so they are a security bug, minor or otherwise.
    >
    > Fortunately you can patch it by hand.

    How do you patch it by hand?

    > > And as for reopening O_NODE files with increased permission: that's
    > > feature people actually expressed interest in, so it's hardly a
    > > security hole, is it?
    >
    > Its a very unexpected semantic particularly for a passed file handle.

    All of this is about new and unexpected semantics. I don't think
    anything more needs to be done than document it in the manpage:

    "A file descriptor opened with O_NODE | O_NOACCESS may be used to
    re-open the same file later with increased permissions
    (e.g. O_RDWR) if the access mode allows. This is true even if the
    permissions on the path leading up to the file would prevent it"

    > > > Wrong way around. The defailt should be that O_NODE fails for any handle
    > > > which has not specifically added support.
    > >
    > > Why? O_NODE can be nicely implemented without any filesystem support.
    >
    > So that you audit the behaviour for unexpected surprises as you go. And
    > in most filesystem cases that consists of "dum de dum, nothing to see,
    > add default handler, tick".
    >
    > But that isn't the case for some things - consider CIFS and other network
    > file systems.

    Why?

    Why would the server need to know anything about that? O_NODE is
    similar to a chdir() in this respect, and chdir doesn't have a handler
    either.

    > > > You also need to address the open with no permissions pinning a removable
    > > > device question.
    > >
    > > The whole point of O_NODE is that it doesn't do that, it only goes as
    > > far as the mnt/dentry for the filesystem node and not further. It
    > > does not get to touch the device at all, so it can't pin it or have
    > > any other side effect.
    >
    > You have a reference to the mnt/dentry pinned so how will you unmount the
    > volume ?

    Oh, I see what you are getting at. So the situation is this: the root
    of the volume does not allow any access to the user, so normal
    open/chdir won't work. Yet open(O_NODE) will and so user can pin the
    volume.

    However, there's not all that much difference between the above and
    doing "stat()" on the mountpoint in a tight loop, except the former is
    a more reliable way to prevent unmounting.

    I don't see this as a huge issue, but ideas about handling it better
    are welcome.

    Thanks,
    Miklos


    \
     
     \ /
      Last update: 2009-11-05 16:27    [W:2.126 / U:0.112 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site