https://bugzilla.novell.com/show_bug.cgi?id=285101#c15 --- Comment #15 from Miklos Szeredi <mszeredi@novell.com> 2007-07-27 11:20:52 MST --- (In reply to comment #14 from Bernhard Kaindl)
Having been asked by coolo to take charge, I put together what we should do:
1) Changes to the init script, also targetted for umounting fuse on shutdown: -----------------------------------------------------------------------------
I think from how I understand the last comments in this report and bug 293429 (fuse should be stopped before the fuse filesystems get killed on shutdown), we have no problem to move fuse rc script from boot.fuse to normal rc script in runlevels 2 3 and 5.
OK, I concur on this one.
2) Possible measures to not start fuse when not needed or not requested
2.1) Start fuse on demand. I don't know how to do this best, at least in a default SuSE setup, it should in theory be possible, but loading a module needs root privileges:
2.1.1) On openSUSE, /usr/bin/fusermount is suid-root for all users when the default /etc/permissions.easy is used by SuSEconfig.permssions:
$ grep fusermount /etc/permissions* /etc/permissions.easy:/usr/bin/fusermount root:trusted 4755 /etc/permissions.secure:/usr/bin/fusermount root:trusted 4750 /etc/permissions.paranoid:/usr/bin/fusermount root:trusted 0755
As %run_permissions is in %post of fuse, that is also being taken care of when the fuse rpm is manually installed.
Thus, fusermount could be used to trigger the module load and could also mount the fusectl filesystem (like ntfs-3g is doing when it has root privileges - it also creates /dev/fuse in case udev is not running)
This is wrong. In the (not so) long run we want to get rid of suid fusermount. The unprivileged mount patches are already in -mm, so 2.6.24 is not unrealistic. This may not make it into OpenSUSE-10.3, but I think relying on fusermount to load the module is not a good direction to take.
This will not be neccessary for ntfs-3g tough, because as of coolo's comment to bug 293429#c2, it seems that we'll go with a suid ntfs-3g.
2.2) Start fuse only when filesystems which use fuse are installed, so we could for examle move the %{insserv_force_if_yast boot.fuse} from %post of fuse to the %post of curlftpfs encfs fuseiso fusepod fusesmb gphotofs obexfs sshfs and wdfs which means that then fuse is only started when they are installed.
No, I think there's no problem with unconditionally loading the module if the fuse package is installed. If the user doesn't want this, then (s)he should remove the package. The _real_ bug in this case was a wrong dependency on fuse, but that has been resolved, so I think this is not an issue any more.
Mentioned in the discussion has also been:
3) Split fuse into fuse and libfuse2. It would generally be advised by http://en.opensuse.org/Packaging/Shared_Library_Packaging_Policy to split fuse into fuse and libfuse2, but as libfuse calls fusermount and libulockmgr starts ulockmgr_server, libfuse2 will require fuse of the same version, so both rpms would need to be installed at once, because fuse automatically has a dependency on libfuse2. So to have any gain of splitting off libfuse2, which would normally be to be able to have two versions of libfuse installed, we'd need to have two fuse rpms installed also, which means that we'd have to add the SONAME major of fuse to the main rpm, which means that we'd have to use fuse2 and libfuse2 in order to have them coexist with fuse3 and libfuse3, but this also means that fusermount and ulockmgr_server need to be renamed to fusermount2 and ulockmgr_server2 a symlink would have to supply the default fusermount to the user. That symlink may be possibly be best provided by a new "fuse" rpm which just has the symlink and a possible man page, done like the current gcc rpm which symlinks to gcc42 and requires gcc42. Very complicated in the end.
The fusermount from fuse-3 should be compatible with the one from fuse-2. So there won't be a need to keep two versions of fusermount around. About ulockmgr: actually that's a completely separate thing from fuse, and should probably be packaged separately. I may make it a separate source package in the future.
It it worth it? - Does one need to support old fuse filesystems which still use fuse2 when we will switch to fuse3? Maybe, if we want to support users which have installed their own fuse filesystems and want to be able to update to say openSUSE 11.0 (or so) without breaking their self-installed fuse filesystems. But will the fuse module of the kernel still support fuse2 or may the API change without backwards compatibility?
Fuse-3 will not be ABI compatible, and probably won't be 100% API compatible either. So separate libraries will be needed, at least until filesystem are ported.
In addition, fuse3 would likely have to use fuse3 fstype and provide fusectl3 and would fuse3 then use a fuse3.ko, fuse3 fstype and use /sys/fs/fuse3/connections as mount point for it? I think only if it's done like this, a split would make sense. Wether to do it like this is I think the call of Miklos (as the developer of fuse).
The kernel interface will remain backward compatible. So this is not an issue. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.