On Tue, 30 Sep 2008, Serge E. Hallyn wrote:
quoted text
> Quoting Eric W. Biederman (ebiederm@xmission.com):

quoted text
> > 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.

quoted text
> > 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
--
unsubscribe notice
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/