Re: [RFC] obsoleting /etc/mtab
On Thu, 2007-05-31 at 18:29 +0200, Miklos Szeredi wrote: I started working on adding support for unprivileged mounts[1] to util-linux. The big obstacle seems to be the reliance on /etc/mtab, since that won't be kept up-to-date after mount(2) or umount(2) calls by unprivileged users. snip ... Can someone think of any other problem with getting rid of /etc/mtab? This presents a couple of problems for autofs, version 5. First, autofs will function if /etc/mtab is a symlink to /proc/mounts (or better if we could mount /proc/mounts as the file /etc/mtab). There are however two problems, first for people that have a large number of mounts, particularly direct mounts, the listing of mounts would be terrible. An implementation of automount on an old version of AIX did this and it was just about impossible to tell what mounts where present besides the autofs internal mounts. Solaris uses a mount option, hide or hidden or something which prevents them from being listed and that works fine. We would need to do something like that in all the utilities that read /etc/mtab. The second, and also maybe not such a big issue, is that if there are many autofs entries to read through this has the potential to kill autofs performance for mounting, expiring and checking if something is mounted, whether the entries have a hidden flag or not utilities will still need to read through all the entries. The same performance issue applies for all the utilities that read the mount table. I'd expect a typical small to medium site that makes wide use of direct mounts to have between 500 and 1000 entries in their maps, and so 500 - 1000 autofs direct mount triggers, similar to Solaris. Also, people that have large filers with many exports will have many internal autofs mounts if using the commonly used hosts map, we use a different implementation for this than Solaris so there are less internal autofs mounts than in Solaris, but still many. Ideas? Ian - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] obsoleting /etc/mtab
Miklos == Miklos Szeredi [EMAIL PROTECTED] writes: Miklos So the best solution would be if /etc/mtab were a symlink to Miklos /proc/mounts, and the kernel would be the authoritative source Miklos of information regarding mounts. That would have to be a symlink to /proc/self/mounts, yes? -JimC -- James Cloos [EMAIL PROTECTED] OpenPGP: 1024D/ED7DAEA6 - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] obsoleting /etc/mtab
Peter == H Peter Anvin [EMAIL PROTECTED] writes: Peter /proc/mounts *is* a symlink to /proc/self/mounts. D’oh. I must have read mounts where modules showed up in the ls(1) I ran before writing that. I probably should adjust the cyan used for symlinks in the coloured ls(1) output; it does seem to blend in with the yellowish background. [SIGH] Appologies for the noise. ;^( -JimC -- James Cloos [EMAIL PROTECTED] OpenPGP: 1024D/ED7DAEA6 - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] obsoleting /etc/mtab
On Jun 1 2007 09:35, Karel Zak wrote: NFS takes a binary option block anyway. However, that's the exception, not the rule. I'm not sure, but I think that cifs and ncpfs (NetWare) are exceptions too. And the dying smbfs... Jan -- - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] obsoleting /etc/mtab
On Thu, May 31, 2007 at 06:29:12PM +0200, Miklos Szeredi wrote: It's not just mount(8) that reads /etc/mtab, but various other utilities, for example df(1). So the best solution would be if mount.nfs, mount.cifs, mount.ocfs, HAL, am-utils (amd)... OK, I'll try to round up the people involved and ask how this change would affect their programs. (1) user mounts (user or users option in /etc/fstab) currently need /etc/mtab to keep track of the owner There is more things: loop=/dev/loopN ... umount(8) uses this option for loop device deinitialization, when the device was initialized by mount(8), Hmm, this is basically just a bool flag for each loop device, and could be stored in a file under /var/lib. encryption=, offset=, speed= ... but nothing uses these options uhelper= ... this one is my baby :-( (Not released by upstream yet. ...according to Google this Fedora patch is already in Mandrake, PCLinuxOS, Pardus, and ??? ) From man page: The uhelper (unprivileged umount request helper) is possible used when non-root user wants to umount a mountpoint which is not defined in the /etc/fstab file (e.g devices mounted by HAL). So the helper gets to run _before_ the umount takes place? GNOME people love it, because that's a way how use command line utils (umount(8)) for devices that was mounted by desktop daemons. The umount.nfs also reads many options from mtab, but it seems all these options are also in /proc/mounts. I know almost nothing about the others [u]mount dialects (cifs, ...). (2) lots of filesystems only present a few mount options (or none) in /proc/mounts (1) can be solved with the new mount owner support in the unprivileged mounts patchset. Mount(8) would still have to detect at boot time if this is available, and either create the symlink to /proc/mounts or if MS_SETOWNER is not available, fall back to using /etc/mtab. Sounds good, but there should be a way (an option) to disable this functionality (in case when mtab is required for an exotic reason). Sure, that's a good idea. How do we configure mount(8)? Maybe an option (--no-mtab-symlink), and leave the configuration to userspace. When mount is invoked first on boot (mount -a) this could tell us if the creation of the symlink is not desired. (2) needs work in the filesystems implicated. I already have patches for ext2, ext3, tmpfs, devpts and hostfs, and it would be nice if the maintainers for others could help out. It wouldn't even be fatal if some mount options were missing from /proc/mounts. Mount options in /etc/mtab have never been perfectly accurate, especially after a remount, when they could get totally out of sync with the options effective for the filesystem. The /etc/mtab is almost always useless with NFS (kernel is changing mount options according to NFS server settings, so there is possible that you have rw in mtab and ro in /proc/mounts :-) Can someone think of any other problem with getting rid of /etc/mtab? Crazy idea: make kernel more promiscuous with mount options -- it means you can use an arbitrary foo= option for mount(2) when max length of all options is less than or equal to /proc/sys/fs/mntopt_max. (well... NACK :-) I agree that the /etc/mtab file is badly designed thing where we duplicate almost all from /proc/mounts, but loop= and uhelper= are nice examples that userspace utils are able to capitalize on this concept. Maybe we need something better than the mtab for userspace specific options. Somewhere at people.redhat.com/kzak/ I have a patch that add LUKS support to the mount(8) and this patch also add new options to the mtab file. I can imagine more scenarios when userspace specific options are good thing. So there's a need to attach some metadata to mounts. And preferably that should also be stored in the kernel, otherwise there will just be confusion, when the mount tree is manipulated without the metadata also being updated. And with unprivileged mounts this can only be guaranteed if the metadata is also in the kernel. So, how about a special mount option: uopts=..., which would contain userspace options separated by ; or whatever. Then the kernel could be taught to store this option verbatim and show it in /proc/mounts along with the kernel options. [1] http://lkml.org/lkml/2007/4/27/180 The patches have been postponed by Andrew, right? Or is it already in -mm? Yes, they have now survived for a month in -mm, which might be a good sign ;) Miklos - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] obsoleting /etc/mtab
On Fri, Jun 01, 2007 at 09:49:05AM +0100, Christoph Hellwig wrote: On Fri, Jun 01, 2007 at 10:33:09AM +0200, Karel Zak wrote: The core of the problem is that HAL doesn't have entries in /etc/fstab, so you cannot check for user= and users= by umount(8). The HAL have enough information about user's privileges, but the umount(8) knows nothing. Please don't put this in. The last thing we need is more ugly hacks and suid mess in the mount code. Miklos is working towards proper suid mess? Fortunately, we use external umount programs for all network filesystems. non-privilegued mounts and you should better support him there. Yes, I look forward to his patches, but there is still a fstab check in umount. The current umount(8) code expects user or users option in /etc/mtab (or in Miklos's /proc/mounts) and *also* in /etc/fstab. Maybe the umount(8) code is too much paranoid and we needn't the fstab check, especially with non-suid umount(2). Miklos's patches also add support for a submount under the owned mount -- this is probably next situation when check against fstab is useless. This is a crucial question. The unpriv patches assume, that the owner can unmount, regardless of what's in fstab. The question is: why does umount(8) currently check /etc/fstab? I can imagine, that this is a sort of sanity check, if the mount is really the same as it was (hasn't been moved, remounted, umounted etc). In this case it's OK to get rid of this check, since the kernel will know if something happened to the mount. Or is there some other reason for checking fstab on umount? Miklos - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] obsoleting /etc/mtab
On Fri, Jun 01, 2007 at 09:49:05AM +0100, Christoph Hellwig wrote: On Fri, Jun 01, 2007 at 10:33:09AM +0200, Karel Zak wrote: The core of the problem is that HAL doesn't have entries in /etc/fstab, so you cannot check for user= and users= by umount(8). The HAL have enough information about user's privileges, but the umount(8) knows nothing. Please don't put this in. The last thing we need is more ugly hacks and suid mess in the mount code. Miklos is working towards proper suid mess? Fortunately, we use external umount programs for all network filesystems. non-privilegued mounts and you should better support him there. Yes, I look forward to his patches, but there is still a fstab check in umount. The current umount(8) code expects user or users option in /etc/mtab (or in Miklos's /proc/mounts) and *also* in /etc/fstab. Maybe the umount(8) code is too much paranoid and we needn't the fstab check, especially with non-suid umount(2). Miklos's patches also add support for a submount under the owned mount -- this is probably next situation when check against fstab is useless. Karel -- Karel Zak [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] obsoleting /etc/mtab
On Fri, Jun 01, 2007 at 10:33:09AM +0200, Karel Zak wrote: The core of the problem is that HAL doesn't have entries in /etc/fstab, so you cannot check for user= and users= by umount(8). The HAL have enough information about user's privileges, but the umount(8) knows nothing. Please don't put this in. The last thing we need is more ugly hacks and suid mess in the mount code. Miklos is working towards proper non-privilegued mounts and you should better support him there. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] obsoleting /etc/mtab
Karel Zak [EMAIL PROTECTED] writes: There is more things: uhelper= ... this one is my baby :-( (Not released by upstream yet. ...according to Google this Fedora patch is already in Mandrake, PCLinuxOS, Pardus, and ??? ) and openSuse Factory... I agree that the /etc/mtab file is badly designed thing where we duplicate almost all from /proc/mounts, but loop= and uhelper= are nice examples that userspace utils are able to capitalize on this concept. Maybe we need something better than the mtab for userspace specific options. I agree, we need a way to store userspace specific options. E.g. Suse has also a way to tag NFSv4 export directories which are automatically mounted via bind to the main export directory with an own option and relies on that this option gets propagated to mtab without modification. Matthias - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] obsoleting /etc/mtab
On Fri, Jun 01, 2007 at 09:03:42AM +0200, Miklos Szeredi wrote: uhelper= ... this one is my baby :-( (Not released by upstream yet. ...according to Google this Fedora patch is already in Mandrake, PCLinuxOS, Pardus, and ??? ) From man page: The uhelper (unprivileged umount request helper) is possible used when non-root user wants to umount a mountpoint which is not defined in the /etc/fstab file (e.g devices mounted by HAL). So the helper gets to run _before_ the umount takes place? The helper runs instead the umount(8). That's almost same like /sbin/umount.nfs. For example if you have mtab: /dev/foo /media/hal_hell_mnt iso9990 uhelper=hal when you call as unprivileged user the /sbin/umount command: it detects that you have no permissions, but that there is /sbin/umount.hal and all is redirected (fork(), execv(), ...) to the umount.hal. The umount(8) doesn't do anything with the mointpoint in this case. The core of the problem is that HAL doesn't have entries in /etc/fstab, so you cannot check for user= and users= by umount(8). The HAL have enough information about user's privileges, but the umount(8) knows nothing. http://git.kernel.org/?p=utils/util-linux-ng/util-linux-ng.git;a=commit;h=dd9f213ab6efd352f67bc18071c16239d1002b94 Sounds good, but there should be a way (an option) to disable this functionality (in case when mtab is required for an exotic reason). Sure, that's a good idea. How do we configure mount(8)? Maybe an option (--no-mtab-symlink), and leave the configuration to userspace. When mount is invoked first on boot (mount -a) this could tell us if the creation of the symlink is not desired. Yes. (The mount is invoked first with -n (= no mtab) in early boot time, because the root device is mounted read-only. Later the init scripts use mount -f which doesn't call mount(2), but adds things to mtab only. In this time we need to use --no-mtab-symlink). But that's detail...) Can someone think of any other problem with getting rid of /etc/mtab? Crazy idea: make kernel more promiscuous with mount options -- it means you can use an arbitrary foo= option for mount(2) when max length of all options is less than or equal to /proc/sys/fs/mntopt_max. (well... NACK :-) I agree that the /etc/mtab file is badly designed thing where we duplicate almost all from /proc/mounts, but loop= and uhelper= are nice examples that userspace utils are able to capitalize on this concept. Maybe we need something better than the mtab for userspace specific options. Somewhere at people.redhat.com/kzak/ I have a patch that add LUKS support to the mount(8) and this patch also add new options to the mtab file. I can imagine more scenarios when userspace specific options are good thing. So there's a need to attach some metadata to mounts. And preferably that should also be stored in the kernel, otherwise there will just be confusion, when the mount tree is manipulated without the metadata also being updated. And with unprivileged mounts this can only be guaranteed if the metadata is also in the kernel. There is more scenarios -- for example somewhere in RH bugzilla is waiting request for read-only root filesystem -- in particular case the writable /etc/mtab is problem. So, how about a special mount option: uopts=..., which would contain userspace options separated by ; or whatever. Then the kernel could be taught to store this option verbatim and show it in /proc/mounts along with the kernel options. Yes, something like uopts=... is my wish for long time. [1] http://lkml.org/lkml/2007/4/27/180 The patches have been postponed by Andrew, right? Or is it already in -mm? Yes, they have now survived for a month in -mm, which might be a good sign ;) Cool, good news. Karel -- Karel Zak [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] obsoleting /etc/mtab
On Thu, May 31, 2007 at 05:11:40PM -0700, H. Peter Anvin wrote: Trond Myklebust wrote: A lot of these could be fixed all at once by letting the filesystem tell the VFS to retain the string passed to the original mount. That will Unfortunately, the original option string (from userspace) != real options (in kernel), see NFS. This bug should be fixed -- the kernel has to fully follow mount(2) or ends with EINVAL. Way ahead of you... See patches 6 and 7 on http://client.linux-nfs.org/Linux-2.6.x/2.6.22-rc3/ :-) NFS takes a binary option block anyway. However, that's the exception, not the rule. I'm not sure, but I think that cifs and ncpfs (NetWare) are exceptions too. Karel -- Karel Zak [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] obsoleting /etc/mtab
(2) needs work in the filesystems implicated. I already have patches for ext2, ext3, tmpfs, devpts and hostfs, and it would be nice if the maintainers for others could help out. A lot of these could be fixed all at once by letting the filesystem tell the VFS to retain the string passed to the original mount. That will solve *almost* all filesystems which take string options. On remount some filesystems like ext[234] use the given options as a delta, not as the new set of options. Others just ignore some of the options on remount. Yes, /etc/mtab is broken wrt. remount too, but somehow I feel breaking /proc/mounts this way too would be frowned upon. On the other hand, maybe it's cleaner to present a canonical view of the options. Note that /etc/mtab does not, however. Yes, we could emulate /etc/mtab like this for filesystems which don't have a -show_options(), but mostly filesystems do have -show_options(), they are just lazy about updating it with all the new mount options. Miklos - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] obsoleting /etc/mtab
Hi Miklos, On Thu, May 31, 2007 at 06:29:12PM +0200, Miklos Szeredi wrote: It's not just mount(8) that reads /etc/mtab, but various other utilities, for example df(1). So the best solution would be if mount.nfs, mount.cifs, mount.ocfs, HAL, am-utils (amd)... and these utils also write to mtab, although I think many of them already check for a symlink. /etc/mtab were a symlink to /proc/mounts, and the kernel would be the authoritative source of information regarding mounts. Yes. (1) user mounts (user or users option in /etc/fstab) currently need /etc/mtab to keep track of the owner There is more things: loop=/dev/loopN ... umount(8) uses this option for loop device deinitialization, when the device was initialized by mount(8), encryption=, offset=, speed= ... but nothing uses these options uhelper= ... this one is my baby :-( (Not released by upstream yet. ...according to Google this Fedora patch is already in Mandrake, PCLinuxOS, Pardus, and ??? ) From man page: The uhelper (unprivileged umount request helper) is possible used when non-root user wants to umount a mountpoint which is not defined in the /etc/fstab file (e.g devices mounted by HAL). GNOME people love it, because that's a way how use command line utils (umount(8)) for devices that was mounted by desktop daemons. The umount.nfs also reads many options from mtab, but it seems all these options are also in /proc/mounts. I know almost nothing about the others [u]mount dialects (cifs, ...). (2) lots of filesystems only present a few mount options (or none) in /proc/mounts (1) can be solved with the new mount owner support in the unprivileged mounts patchset. Mount(8) would still have to detect at boot time if this is available, and either create the symlink to /proc/mounts or if MS_SETOWNER is not available, fall back to using /etc/mtab. Sounds good, but there should be a way (an option) to disable this functionality (in case when mtab is required for an exotic reason). (2) needs work in the filesystems implicated. I already have patches for ext2, ext3, tmpfs, devpts and hostfs, and it would be nice if the maintainers for others could help out. It wouldn't even be fatal if some mount options were missing from /proc/mounts. Mount options in /etc/mtab have never been perfectly accurate, especially after a remount, when they could get totally out of sync with the options effective for the filesystem. The /etc/mtab is almost always useless with NFS (kernel is changing mount options according to NFS server settings, so there is possible that you have rw in mtab and ro in /proc/mounts :-) Can someone think of any other problem with getting rid of /etc/mtab? Crazy idea: make kernel more promiscuous with mount options -- it means you can use an arbitrary foo= option for mount(2) when max length of all options is less than or equal to /proc/sys/fs/mntopt_max. (well... NACK :-) I agree that the /etc/mtab file is badly designed thing where we duplicate almost all from /proc/mounts, but loop= and uhelper= are nice examples that userspace utils are able to capitalize on this concept. Maybe we need something better than the mtab for userspace specific options. Somewhere at people.redhat.com/kzak/ I have a patch that add LUKS support to the mount(8) and this patch also add new options to the mtab file. I can imagine more scenarios when userspace specific options are good thing. [1] http://lkml.org/lkml/2007/4/27/180 The patches have been postponed by Andrew, right? Or is it already in -mm? Karel -- Karel Zak [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] obsoleting /etc/mtab
On Thu, May 31, 2007 at 09:40:49AM -0700, H. Peter Anvin wrote: Miklos Szeredi wrote: (2) needs work in the filesystems implicated. I already have patches for ext2, ext3, tmpfs, devpts and hostfs, and it would be nice if the maintainers for others could help out. A lot of these could be fixed all at once by letting the filesystem tell the VFS to retain the string passed to the original mount. That will Unfortunately, the original option string (from userspace) != real options (in kernel), see NFS. This bug should be fixed -- the kernel has to fully follow mount(2) or ends with EINVAL. Karel -- Karel Zak [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] obsoleting /etc/mtab
On Fri, 2007-06-01 at 01:04 +0200, Karel Zak wrote: On Thu, May 31, 2007 at 09:40:49AM -0700, H. Peter Anvin wrote: Miklos Szeredi wrote: (2) needs work in the filesystems implicated. I already have patches for ext2, ext3, tmpfs, devpts and hostfs, and it would be nice if the maintainers for others could help out. A lot of these could be fixed all at once by letting the filesystem tell the VFS to retain the string passed to the original mount. That will Unfortunately, the original option string (from userspace) != real options (in kernel), see NFS. This bug should be fixed -- the kernel has to fully follow mount(2) or ends with EINVAL. Way ahead of you... See patches 6 and 7 on http://client.linux-nfs.org/Linux-2.6.x/2.6.22-rc3/ Trond - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] obsoleting /etc/mtab
On Thu, May 31, 2007 at 09:40:49AM -0700, H. Peter Anvin wrote: Miklos Szeredi wrote: (2) needs work in the filesystems implicated. I already have patches for ext2, ext3, tmpfs, devpts and hostfs, and it would be nice if the maintainers for others could help out. A lot of these could be fixed all at once by letting the filesystem tell the VFS to retain the string passed to the original mount. That will solve *almost* all filesystems which take string options. Except some filesystems mangle that string as it gets passed around (i.e. XFS) Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] obsoleting /etc/mtab
Trond Myklebust wrote: A lot of these could be fixed all at once by letting the filesystem tell the VFS to retain the string passed to the original mount. That will Unfortunately, the original option string (from userspace) != real options (in kernel), see NFS. This bug should be fixed -- the kernel has to fully follow mount(2) or ends with EINVAL. Way ahead of you... See patches 6 and 7 on http://client.linux-nfs.org/Linux-2.6.x/2.6.22-rc3/ NFS takes a binary option block anyway. However, that's the exception, not the rule. -hpa - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] obsoleting /etc/mtab
On May 31, 2007 17:11 -0700, H. Peter Anvin wrote: NFS takes a binary option block anyway. However, that's the exception, not the rule. There was recently a patch submitted to linux-fsdevel to change NFS to use text option parsing. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
