> > Q: Why do we need correct option showing in /proc/mounts? > > A: We want /proc/mounts to fully replace /etc/mtab. The reasons for > > this are: > > - unprivileged mounters won't be able to update /etc/mtab > > - /etc/mtab doesn't work with private mount namespaces > > - /etc/mtab can become out-of-sync with reality > > I asked this before and I don't remember getting an answer: > How does this deal with certain special cases: > - chroot: how will mount/df only show the for chroot relevant mounts? That is a very good question. Andreas Gruenbacher had some patches for fixing behavior of /proc/mounts under a chroot, but people are paranoid about userspace ABI changes (unwarranted in this case, IMO). http://lkml.org/lkml/2007/4/20/147 Anyway, if we are going to have a new 'mountinfo' file, this could be easily fixed as well. > - loop: how is the connection between file and loop device maintained? We also discussed this with Karel, maybe it didn't make it onto lkml. The proposed solution was to store the "loop" flag separately in a file under /var. It could just be an empty file for each such loop device: /var/lib/mount/loops/loop0 This file is created by mount(8) if the '-oloop' option is given. And umount(8) automatically tears down the loop device if it finds this file. > I don't quite see how you want to achieve a _full_ replacement. I think a full replacement is perfectly feasible, just needs some more work on the userspace side. > Could also please explain why you want to go via user mounts. Other OS use a > daemon for that, which e.g. can maintain access controls. How do you want to > manage this? The unprivileged mounts patches do contain a simple form of access control. I don't think anything more is needed, but of course, having unprivileged mounts in the kernel does not prevent the use of a more sophisticated access control daemon in userspace, if that becomes necessary. 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
