lkml.org 
[lkml]   [2008]   [Sep]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: unprivileged mounts git tree
    "Serge E. Hallyn" <serue@us.ibm.com> writes:

    >> > So in order for me as an unprivileged user to pin a dentry by mounting
    >> > over it, I have to have write permission to the dentry to begin with
    >> > as well as the dentry being under a user=hallyn mount.
    >>
    >> That second condition is interesting requiring write permission of the
    >> dentry. I thought we had obviated the need for that when we added
    >> ownership to the mounts themselves. In this case at least it shouldn't
    >> it be write permission on the directory containing the dentry.
    >
    > Oh no, it seems I'm wrong, that's not a condition. Just tested it.

    Ok. I couldn't find Mikolos's code when I looked quickly.
    What are the current rules? It sounds like my original example could apply.

    >> This seems to mess up things like revoke.
    >
    > Hey, do we have revoke now? :)

    Periodically someone works on revoke ;)

    >> At a practical level it is a real annoyance, regardless of the security
    >> implications.
    >>
    >> As a point of comparison plan9 does not have that restriction.
    >
    > Why doesn't it have that restriction?

    I haven't heard the reason.

    > Does it always allow you to rm a mounted-over file?

    Yes.

    The implementation of mounts in plan9 is a bit different. In
    plan9 mounts are looked up by mount namespace and qid (effectively
    the inode number). So the semantics are slightly different.
    Requiring a new mount namespace if you want to see what a filesystem
    looks like without a mount on top of a given file.

    It also looks like plan9 is likely to have a unmountable and unusable mount
    if you actually delete an file, from another mount namespace.

    Linux actually has a very similar case where we can loose a mount if you rename
    the directory that contains it to be somewhere higher in the mount hierarchy
    than the location the mount was under.

    All of that said there is a very good practical justification for it all.
    In a filesystem where not all changes come through our local VFS the
    VFS cannot prevent changes to a filesystem it can only cache and respond
    to changes that do occur.

    So things like sysfs_rename_dir and sysfs_move_dir routinely bypass
    the VFS restriction against changes happening under mount points. It
    isn't a problem in practice because people don't mount on sysfs but the
    problem is very much there today.

    It looks to me like the right solution is very much to do the lazy
    unmount we do for expired mounts, and purge everything that happens
    and then we just don't have to worry about mounts causing a denial
    of service attack and life gets simpler.

    Rename is a bit trickier than unlink and rmdir in that we should allow
    it on the underlying filesystem and only remove the directory if the
    rename goes out of scope for the overlying mount.

    Eric


    \
     
     \ /
      Last update: 2008-09-14 05:17    [W:3.472 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site