> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
