[Bug 285101] New: fuse module loaded by default
https://bugzilla.novell.com/show_bug.cgi?id=285101 Summary: fuse module loaded by default Product: openSUSE 10.3 Version: Alpha 5 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem AssignedTo: mszeredi@novell.com ReportedBy: coolo@novell.com QAContact: qa@suse.de Found By: --- Doing this bug report to find out / document the reason we load the fuse module a) in our default selection b) that early in the boot process The fuse module seems to waste time and memory on my system. -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=285101#c1
Miklos Szeredi
Doing this bug report to find out / document the reason we load the fuse module a) in our default selection b) that early in the boot process
The fuse module seems to waste time and memory on my system.
Any fuse filesystem is unusable without the fuse module first being loaded. The default was added, so that filesystems like sshfs, encfs, etc. work out of the box without having to do additional configuration. It is based on the assumption, that the fuse package is only installed if the user needs it's functionality. Why do you have the fuse package installed if you do not intend to use it? -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=285101#c2
--- Comment #2 from Stephan Kulow
https://bugzilla.novell.com/show_bug.cgi?id=285101#c3
--- Comment #3 from Miklos Szeredi
libfuse.so.2 is needed by (installed) compiz.
I don't use compiz either on this very laptop, but it's installed by default. So is fuse. So is boot.fuse -> modprobe
Hmm, so fuse gets pulled in by some weird dependency. Not enabling by default will result in bug reports for "I have installed foofs, but it won't work". See bugs #179618, #222899, #223663 Do you have any other suggestion for solving this? -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=285101#c4
--- Comment #4 from Stephan Kulow
https://bugzilla.novell.com/show_bug.cgi?id=285101#c5
Miklos Szeredi
well, I don't know the reasons compiz requires libfuse, but splitting that package out of fuse would help there.
Right, that makes sense.
So sshfs would require fuse, the loaded module while compiz requires the library. But that doesn't mean fuse, the loaded module, is in the default selection.
According to compiz changelog, here's the culprit: - FUSE plugin that maps compiz options to a file-system and allow efficient manipulation of options by reading and writing files. Matthias, can you tell us, if this is some integral part of compiz, or an optional feature, that could be split into a separate package? -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=285101#c7
Stephan Kulow
https://bugzilla.novell.com/show_bug.cgi?id=285101#c8
--- Comment #8 from Miklos Szeredi
I just talked with Matthias (didn't know he was on NEEDINFO too :): it's an unused plugin and will be split into a subpackage not installed.
That sounds good.
But I think fuse package should be changed by two means: - split the library into a library package
I don't have strong opinions either way. Is there some policy in SUSE about subpackages?
- don't modprobe in a boot.*, but make it a normal rc script in runlevel 2 3 5
Well, in theory we can have fuse based filesystems mounted from /etc/fstab, which means, that the modprobe has to run before boot.localfs. But probably this is not very well thought out or tested yet. But if SUSE wants proper ntfs-3g support for example, this is something that needs to be looked at, and it means that fuse does need to be started early. -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=285101#c10
--- Comment #10 from Stephan Kulow
https://bugzilla.novell.com/show_bug.cgi?id=285101#c11
--- Comment #11 from Miklos Szeredi
What speaks against fuse before .localfs btw is that its tool is from /usr
Right. That'll actually be fixed in fuse-2.7, as 'fusermount' will no longer be necessary if the mounter has enough privileges. As to individual filesystems, it should be decided on a case-by-case basis. Possibly ntfs-3g is something people would never want to use as a /usr partition, but maybe some other fuse based filesystem could be used as /usr. In that case the filesystem executable must necessarily reside on the root fs. So generally assuming the fuse module won't be needed till after boot is wrong I think. -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=285101#c12
--- Comment #12 from Stephan Kulow
https://bugzilla.novell.com/show_bug.cgi?id=285101#c9
--- Comment #9 from Stephan Kulow
https://bugzilla.novell.com/show_bug.cgi?id=285101#c13
Szabolcs Szakacsits
https://bugzilla.novell.com/show_bug.cgi?id=285101
Stephan Kulow
https://bugzilla.novell.com/show_bug.cgi?id=285101#c14
Bernhard Kaindl
https://bugzilla.novell.com/show_bug.cgi?id=285101#c15
--- Comment #15 from Miklos Szeredi
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.
https://bugzilla.novell.com/show_bug.cgi?id=285101#c16
--- Comment #16 from Stephan Kulow
https://bugzilla.novell.com/show_bug.cgi?id=285101#c17
--- Comment #17 from Miklos Szeredi
https://bugzilla.novell.com/show_bug.cgi?id=285101#c18
--- Comment #18 from Stephan Kulow
https://bugzilla.novell.com/show_bug.cgi?id=285101#c19
--- Comment #19 from Miklos Szeredi
https://bugzilla.novell.com/show_bug.cgi?id=285101#c20
--- Comment #20 from Stephan Kulow
https://bugzilla.novell.com/show_bug.cgi?id=285101#c21
--- Comment #21 from Miklos Szeredi
https://bugzilla.novell.com/show_bug.cgi?id=285101#c22
--- Comment #22 from Péter Kerékfy
https://bugzilla.novell.com/show_bug.cgi?id=285101#c23
--- Comment #23 from Bernhard Kaindl
https://bugzilla.novell.com/show_bug.cgi?id=285101#c24
--- Comment #24 from Bernhard Kaindl
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.
and
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.
As of this moment you are wrong, the current compiz still includes this file: ldd /usr/lib64/compiz/libfs.so libfuse.so.2 => /lib64/libfuse.so.2 (0x00002b5e49bc8000) http://compiz.org/Compiz_0.5 Fs plugin: FUSE plugin that maps compiz options to a file-system and allow efficient manipulation of options by reading and writing files. I talked with our compiz maintainer: It would be the next thing on his list, and it's really not used anywhere yet, so it would not be a problem to not install it but OTOH, it would be the only plugin which is splitted into a separate package (compiz has LOTS of plugins) and if libfuse would be in its own package, it would totally not make sense to split it into a separate package, just for this single file. As ntfs-3g (unless I link it statically) need libfuse and long as it is used with root privileges, it does not need fusermount installed or fuse started in any way, we could solve this by splitting off fuse to: * libfuse2 - contains libfuse (is installed when ntfs-3g is installed) * fuse2 - contains fusermount, mount.fuse, the rc script and docs and possibly separate ulockmgr packages. Regarding that: As far as I can see, none of the openSUSE-included rpms which use fuse (checked curlftpfs encfs fuseiso fusepod fusesmb gphotofs obexfs sshfs wdfs and compiz) use libulockmgr, so I guess that it does not make huge sense to ship it? -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=285101#c25
--- Comment #25 from Miklos Szeredi
https://bugzilla.novell.com/show_bug.cgi?id=285101#c26
--- Comment #26 from Miklos Szeredi
As ntfs-3g (unless I link it statically) need libfuse and long as it is used with root privileges, it does not need fusermount installed or fuse started in any way, we could solve this by splitting off fuse to:
* libfuse2 - contains libfuse (is installed when ntfs-3g is installed) * fuse2 - contains fusermount, mount.fuse, the rc script and docs
I'd call the package just "fuse" or "fuse-utils". Otherwise this sounds fine. Do we want *fs packages to depend on the fuse package? Or should the user need to install fuse separately to have a working filesystem?
and possibly separate ulockmgr packages. Regarding that:
As far as I can see, none of the openSUSE-included rpms which use fuse (checked curlftpfs encfs fuseiso fusepod fusesmb gphotofs obexfs sshfs wdfs and compiz) use libulockmgr, so I guess that it does not make huge sense to ship it?
I'm not yet aware of any users, so can just drop it for the moment. -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=285101#c27
--- Comment #27 from Bernhard Kaindl
* fuse2 - contains fusermount, mount.fuse, the rc script and docs I'd call the package just "fuse" or "fuse-utils".
Yes, didn't think that though. Indeed I think just "fuse" (or "fuse-utils, I'm not sure what is best) fuse or fuse-utils should be without version in the name because when fuse goes 3.x, an update upgrades the fuse or fuse-utils package to fuse-3.x and that works as fusermount of fuse-3.x will be compatible with libfuse2.
Otherwise this sounds fine. Do we want *fs packages to depend on the fuse package? Or should the user need to install fuse separately to have a working filesystem?
Normally, way we'd do such things this way: If a package is installed, it should be basically or mostly useable without having to install further packages, this is the whole point of having package dependices, so I'd say. As to what they should require, I think that instead of requiring "fuse" or "fuse-tools", they may (in case we may change the name of the package or split furhter) also require specifically fusermount, either by requiring /usr/bin/fusermount as path, but as they do not need it in a specific path, they may also require just have "fusermount" and the whichever package provides fusermount would then have "Provides: fusermount", independent of it's name. The label could also include the API of the fusermount requiured and provided, e.g. "fusermount-v2" would also be possible. At the moment, I think I prefer such provides/requires string with such API version added as that would give total freedom on which package provides it and it also means that one is free to drop that provides once that API is not longer provided or moved to a different package. I know this is very very generic, but this way the control is over the provides string and that's very flexible. -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=285101#c28
--- Comment #28 from Miklos Szeredi
* fuse2 - contains fusermount, mount.fuse, the rc script and docs I'd call the package just "fuse" or "fuse-utils".
Yes, didn't think that though. Indeed I think just "fuse" (or "fuse-utils, I'm not sure what is best)
Debian calls it "fuse-utils", but just "fuse" is equally fine I think. Since we already have a "fuse" package, I'd suggest sticking with this, which would be less confusing to users.
fuse or fuse-utils should be without version in the name because when fuse goes 3.x, an update upgrades the fuse or fuse-utils package to fuse-3.x and that works as fusermount of fuse-3.x will be compatible with libfuse2.
Right.
As to what they should require, I think that instead of requiring "fuse" or "fuse-tools", they may (in case we may change the name of the package or split furhter) also require specifically fusermount, either by requiring /usr/bin/fusermount as path, but as they do not need it in a specific path, they may also require just have "fusermount" and the whichever package provides fusermount would then have "Provides: fusermount", independent of it's name.
Again, I think this is wrong, because in the long term fusermount won't be needed, yet the fuse package with the init script to initialize the module and mount the control filesystem _will_ be needed. So just adding a dependency on "fuse" is the right thing IMO. -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=285101#c29
--- Comment #29 from Bernhard Kaindl
https://bugzilla.novell.com/show_bug.cgi?id=285101#c30
--- Comment #30 from Miklos Szeredi
https://bugzilla.novell.com/show_bug.cgi?id=285101#c31
--- Comment #31 from Bernhard Kaindl
https://bugzilla.novell.com/show_bug.cgi?id=285101#c32
Bernhard Kaindl
participants (1)
-
bugzilla_noreply@novell.com