From: Csaba H. <csa...@cr...> - 2005-11-08 14:05:06
|
On 2005-11-08, Miklos Szeredi <mi...@sz...> wrote: >> Why does the latter work? Because the gatekeeper is setuid root. >> Otherwise the whole thing would break, we couldn't get nobody's daemon >> mounted. >> >> There is no sensible compromise between the two approaches. If you keep >> mounting on the event chain of the daemon, you need a setuid dispatcher >> to do the touchy part of the job. > > Not necessarily. A 'run_as=USER' generic filesystem option could be > useful to change UID/GID/groups to that of USER. This could be used > for example to automatically mount an sshfs of a specific user from > /etc/fstab, without having to copy keys, etc. Some restructuring > would be needed in sshfs for this, but IAFAICS it's possible to do. I don't get it. We assume that a) setuid bits raus! b) daemon runs unprivileged c) daemon initiates mounting, too d) kernel accepts "mount()" only with uid 0 then we get that the daemon won't be mounted, don't we? As of now, a), b) d) are realistic on FreeBSD (I digress on d) below), and the Linux-style UI would bring in c), too... Regarding fstab: note that in FreeBSD /etc/fstab is not used for propagating mounting privileges like it's done in Linux with the "user(s)" options. It's used in system initialization, and as a "phone book" to save the sysadmin from typing much, and for nothing else. (Mounting privileges are controlled via the sysctl interface and device permissions, in case of device based filesystems [like ufs or fuse, but unlike procfs].) > The ultimate goal is to make the mount() syscall unprivileged for > certain tasks, such as mount a FUSE filesystem. After this the whole > messing with fusermount can go away, and mounting can be done inside > the daemon. Yes, it would be nice if you could achieve this (LKML lobbying, eh? :) ). But mounting a non-privileged daemon shouldn't require that non-privileged mounts are allowed, IMHO. >> So making a setuid dispatcher is not an option under FBSD, and without >> that the daemon-initiates-mount scheme is broken. > > Why? If I understand correctly, this makes it possible for the daemon > call the mount() syscall directly without any suid dispatcher in the > way. The only thing needed is to tune the policy in kernel to allow > FUSE mounts, no? The range of available policies in FreeBSD is rather simplistic, btw. - vfs.usermount=1 : anyone can mount with sufficient privileges over the mountpoint and the device, if there is one (but no module autoloading for non-privileged users). - vfs.usermount=0 (default): only root can mount. If you are in a production environment, maybe you don't want vfs.usermount=1. That's a pretty much liberal setting... (Eg., in respect of fuse, this makes the following possible for johndoe: mount fusexmp over ~johndoe/fusexmp; mkdir /tmp/johndoe; null mount ["bind mount" in Linux] ~johndoe/fusexmp/tmp/johndoe over /tmp/johndoe. This will deadlock fusexmp, of course. That's not a big problem, but there is a chance that in turn, some bug will be triggered which crashes the system. Actually this was the case, until I fixed that bug. But how many similar bugs are there still hiding? You couldn't play such tricks in Linux...) So it's pretty realistic that a sysadmin leaves vfs.usermount on 0, but wants to mount a non-privileged sshfs. The current "well-separated" implementation makes it easy. >> But then it's better then to keep the fd with us, and pass that one to the >> daemon as is. And it's race free. > > OK, I think I see the difference now. Cool! > Oh yes. The close(fd) is not needed then, it's just a remnant from an > old version. Nice find! :) > > So then you need to change the order of fuse_destroy() and > fuse_unmount() to make unmount work. I don't see anything wrong with > doing that. OK, that sounds sane. I will then refurbish my fuse_umount() code. Csaba |