Mailinglist Archive: opensuse-bugs (6120 mails)
| < Previous | Next > |
[Bug 285101] fuse module loaded by default
- From: bugzilla_noreply@xxxxxxxxxx
- Date: Fri, 27 Jul 2007 10:52:24 -0600 (MDT)
- Message-id: <20070727165224.41360CC792@xxxxxxxxxxxxxxxxxxxxxx>
https://bugzilla.novell.com/show_bug.cgi?id=285101#c14
Bernhard Kaindl <bk@xxxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kerekfyp@xxxxxxxx, mszeredi@xxxxxxxxxx
Status|NEW |ASSIGNED
--- Comment #14 from Bernhard Kaindl <bk@xxxxxxxxxx> 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.
Bernhard Kaindl <bk@xxxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kerekfyp@xxxxxxxx, mszeredi@xxxxxxxxxx
Status|NEW |ASSIGNED
--- Comment #14 from Bernhard Kaindl <bk@xxxxxxxxxx> 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.
| < Previous | Next > |