Spec Name or Url: http://homepages.nildram.co.uk/~phekda/richdawe/fedora/FC4/fuse.spec
SRPM Name or Url: http://homepages.nildram.co.uk/~phekda/richdawe/fedora/FC4/fuse-2.4.1-1.src.rpm
Description:
From the FUSE README:
"FUSE (Filesystem in Userspace) is a simple interface for userspace programs to export a virtual filesystem to the linux kernel. FUSE also aims to provide a secure method for non privileged users to create and mount their own filesystem implementations."
FUSE was incorporated and ships in kernel-2.6.14-1.1637_FC4. But to be able to write userspace filesystems, you need the userspace libraries and utilities. I've packaged them up according to the Extras guidelines. Please review them.
Note that there are currently some rpmlint failures (see below). I don't think these are errors. I opened bug #173341 <https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173341> about the udev rules; I think they belong in the udev package in the future.
[rich@katrina FC4]$ rpmlint i386/fuse-2.4.1-1.i386.rpm
W: fuse non-conffile-in-etc /etc/udev/rules.d/40-fuse.rules
E: fuse setuid-binary /usr/bin/fusermount root 04755
E: fuse non-standard-executable-perm /usr/bin/fusermount 04755
[rich@katrina FC4]$ rpmlint i386/fuse-devel-2.4.1-1.i386.rpm
[rich@katrina FC4]$ rpmlint fuse-2.4.1-1.src.rpm
Please let me know if you'd like some detailed instructions on how to get a userspace filesystem up and running with FUSE.
Also, thanks for reviewing in advance!

Hi Thorsten.
It looks like you've already done a lot of work on this. I agree - we should go
with what's been discussed already. I'll try to review the packages at the
weekend - if I don't, please proceed anyway.
This is my own fault. I should have checked fedora-extras-list!
Thanks, bye, Rich

Hi Thorsten,
Thanks for packaging FUSE.
About security: FUSE has been designed in a way, that even malicious users
can't cause problems. This is modulo any unknown bugs of course. To date there
has been only one security bug found (an information leak) and fixed in 2.3.0
that could be exploited by a hostile user.
So restricting mounting to a subset of users IMO just makes administration
harder. So at least it should be documented that it's an option for the
sysadmin to change the mode of /usr/bin/fusermount to 4755 instead of having to
individually add users to the fuse group.
Thanks,
Miklos

Packaging /usr/bin/fusermount as 0755 and expecting the sysadmin to set it to
4755 in order to use it is not a good option, because upon package update it
will change the permission back to the default. Red Hat engineering is now
assessing our options about what exactly to do with FUSE userspace tools and
exactly how we will ship it by default. It will probably be a week or two
before we come to any conclusions because we are currently busy trying to get
FC5test1 out the door. In the mean time if you have any further information
about the security risks of this, including any proof of code audits or design
details of the system please submit links here for our analysis.

The discussion here already start to resemble what we already had on the
Fedora Extras list. The points raised was these:
1. Some people expressed disbelief in the FUSE security system, and
wanted to restrict its use to things listed in /etc/fstab. A
special concern raised was that sshfs would be able to mount most
anything.
2. Protest from me (perhaps some others too) that this was not good,
and actually, just mounting things listed in /etc/fstab is not
what FUSE is intended for. (See package description above!)
IMHO the most reasonable thing is to package FUSE suid root as the
developers intended it, and the developers claim this is secure.
If sysadmins don't like the goals of the FUSE project or do not
believe it is secure though it's claimed to be, they should not
install the FUSE packages at all.
With respect to the worry of sshfs mounting just anything, the
way suid-mounting something using sshfs+FUSE would be different
from using GNOME VFS on top of common ssh evades me totally.
Just that the kernel is involved and something is run suid root
doesn't change the basic concept, its just a matter of whether
kernel VFS or GNOME VFS is involved in the operation, the result
is the same: user mounts whatever user wants and that's cool.
FUSE provides infrastructure for a lot of nice userland things
and sshfs will presumably not be the most interesting thing
that can be done with it, so I discourage this narrow focus on
one single application. I have been waiting for FUSE so that
I can then package EncFS, a use case that would be destroyed or
hampered beyond repair by crippling fusermount like this.
Sorry if stressing my opinion this hard hurts anyones feelings.
I'm no sysadmin so please enlighten us to where exactly the
problems with FUSE+sshfs are, I don't get it, could be out of
my ignorace or misinformedness.

I my view the fuse group is too restrictive. I potentally want any user to mount
a USB stick in a LTSP environment. I don't want to add users to a group, I want
anyone to be able to do this. I have over 20,000 usernames in an LDAP server.
I want to trust to security of the fuse userland tools. If there is a problem
there then the tools must be fixed.

(In reply to comment #7)
> I my view the fuse group is too restrictive.
Several other people say: Shipping programms suid root is a security risk -- we
have seen that in the past with several programms and therefor avoid suid root
as much as possible.
I agree with that opinion. But fuse simply does not work without suid root
(note: smbfs, cifs, ncpfs and several other do). So the fuse group is a compromise.
> I potentally want any user to mount
> a USB stick in a LTSP environment.
Interesting environment where users have direct access to physical devices. And
mounting a USB-Stick works for me on recent Fedora versions without fuse. But
that is a diffenrent story. So back on topic:
> I don't want to add users to a group, I want
> anyone to be able to do this.[...]
> I want to trust to security of the fuse userland tools.
Then do a chmod 0755 /usr/bin/fusemount. You are free to do that, I won't complain.

(In reply to comment #4)
> Packaging /usr/bin/fusermount as 0755 and expecting the sysadmin to set it to
> 4755 in order to use it is not a good option, because upon package update it
> will change the permission back to the default.
An alternative is to restrict access to /dev/fuse and install
/usr/bin/fusermount with 4755.
> In the mean time if you have any further information
> about the security risks of this, including any proof of code audits or design
> details of the system please submit links here for our analysis.
No security audit has been done on any part of FUSE. Prior to inclusion into
Linux, the kernel part was reviewed by a couple of people, but without special
attention to security.
The above alternative would "only" require an audit of fusermount, but of course
a full audit (kernel module + fusermount) would be nice.
The long term goal is to make mount() syscall unprivileged (with policy
controllable via sysctl and ulimit), and so remove the requirement for a suid
mount helper. The earliest this could happen is 2.6.16.

I APPROVE of Thorsten's fuse package. We need to give this technology a chance
in Extras to see how it goes.
Thorsten perhaps submit sshfs to another bug for review and approval?
Has anyone packaged encfs too? That sounds interesting.