On Tue, 30 Sep 2008, Serge E. Hallyn wrote: > Quoting Eric W. Biederman (ebiederm@xxxxxxxxxxxx): > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
