Quoting Miklos Szeredi (miklos@xxxxxxxxxx): > > > One thing that is missing from this series is the ability to restrict > > > user mounts to private namespaces. The reason is that private > > > namespaces have still not gained the momentum and support needed for > > > painless user experience. So such a feature would not yet get enough > > > attention and testing. However adding such an optional restriction > > > can be done with minimal changes in the future, once private > > > namespaces have matured. > > > > What is the main reason for that feature? Would it be to prevent things > > like login from being tricked by user mounts? Isn't it sufficient, in > > fact, better, to require that the target of the mount be owned by the > > user doing the mount? > > It's been discussed later in that thread. Basically you can fool a I see now, sorry. > lot of system programs (like backup) with mounting/binding in the > global namespace. Restricting the destination doesn't always help. > > Miklos It would be nice in general if we could avoid any sort of checks for (mnt->mnt_ns == init_nsproxy.mnt_ns). Maybe that won't be possible, but, taking the two listed examples: 1. mount --bind / ~/bindns; (later) userdel hallyn I assume userdel does a simple stupid rm -rf without first umounting, then? So (1) it seems wise to have userdel umount anything under ~user first anyway, and (2) if $USER does a mount --bind from a source he doesn't own, should we make the resulting mount read-only? (realizing the read-only bind mount patches are still under development :) Or is that overly restrictive somehow for fuse? 2. backups Is this just a 'he's going to fill up the whole disk' issue? Frankly, it seems wise to have cron or whatever is spawning the backup start in it's own namespace right at boot. Generally when I think back on sites where I've dealt with backup, backups were done on a separate server which didn't allow userlogins anyway, so it wouldn't be a problem. But I'm sure that's a limited (==erroneous) POV. I do realize that the whole problem about corner cases isn't addressing two little ones, but the fact that there are more we haven't thought of. So are there any currently known use cases where requiring a CLONE_NEWNS before user mounts is unacceptable? thanks, -serge - 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
