lkml.org 
[lkml]   [2008]   [Oct]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: unprivileged mounts git tree
From
Date
On Tue, 30 Sep 2008, Serge E. Hallyn wrote:
> Quoting Eric W. Biederman (ebiederm@xmission.com):

> > 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.
>
> Rules according to permit_mount:
>
> if CAP_SYS_ADMIN, allowed
> if fs type is not marked safe for user mounts (and not bind), -EPERM
> if target is a link, -EPERM
> if target is labeled with new nosubmnt flag, -EPERM
> if target is not a user mount owned by current->uid, -EPERM
> if recursive bind mount, -EPERM (?)

The rationale for the last one is that the user might not have access
to the submounts. Recursive bind mounts can be implemented in
userspace if needed.

> > 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.
>
> Can you give an example?

# mkdir -p /tmp/a/b/c
# mkdir /tmp/x
# mount --bind /tmp/a /tmp/x
# mount --bind /bin /tmp/x/b/c
# mv /tmp/a/b/c /tmp
mv: cannot move `/tmp/a/b/c' to `/tmp/c': Device or resource busy
# mv /tmp/a/b /tmp
# ls -al /tmp/x
total 64
drwxr-xr-x 2 root root 4096 Oct 6 12:55 .
drwxrwxrwt 95 root root 57344 Oct 6 12:55 ..
# umount /tmp/x
umount: /tmp/x: device is busy.

The mount under /tmp/x/b/c is now inaccessible and lost forever. The
only way to get rid of it is to lazy umount /tmp/x itself.

What this means is that the current EBUSY restriction only prevents
the mountpoint disappearing in a subset of cases.

Miklos


\
 
 \ /
  Last update: 2008-10-06 13:09    [W:0.074 / U:0.136 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site