https://bugzilla.novell.com/show_bug.cgi?id=285101#c14 Bernhard Kaindl <bk@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kerekfyp@komal.hu, mszeredi@novell.com Status|NEW |ASSIGNED --- Comment #14 from Bernhard Kaindl <bk@novell.com> 2007-07-27 10:52:23 MST --- 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. 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 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. When the expression "$YAST_IS_RUNNING" != "instsys" is true, we could also start fuse from %post, a number of rpms use YAST_IS_RUNNING in their scripts, so that should not be useable. We'll not need anything like that in ntfs-3g, as (it seems) we are going to make it suid and it can start fuse itself then. 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. 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? 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). -- 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.