Mailinglist Archive: opensuse-bugs (6120 mails)
| < Previous | Next > |
[Bug 285101] fuse module loaded by default
- From: bugzilla_noreply@xxxxxxxxxx
- Date: Fri, 27 Jul 2007 11:20:53 -0600 (MDT)
- Message-id: <20070727172053.6CCF2CC78D@xxxxxxxxxxxxxxxxxxxxxx>
https://bugzilla.novell.com/show_bug.cgi?id=285101#c15
--- Comment #15 from Miklos Szeredi <mszeredi@xxxxxxxxxx> 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.
--- Comment #15 from Miklos Szeredi <mszeredi@xxxxxxxxxx> 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.
| < Previous | Next > |