[patch 7/9] unprivileged mounts: allow unprivileged fuse mounts
pavel at ucw.cz
Wed Jan 9 03:33:25 PST 2008
> > > AFAIR there were two security vulnerabilities in fuse's history, one
> > > of them an information leak in the kernel module, and the other one an
> > > mtab corruption issue in the fusermount utility. I don't think this
> > > is such a bad track record.
> > Not bad indeed. But I'd consider 'kill -9 not working' to be DoS
> > vulnerability...
> The worst that can happen is that a sysadmin doesn't read the docs
> (likely) before enabling fuse on a multiuser system, and is surprised
> by a user doing funny things. And _then_ has to go read the docs, or
> google for some info. This is basically how things normally work, and
> I don't consider it a DoS.
No, this is not normal. Kill -9 has been estabilished long time ago,
and we should not be documenting its now-brokenness in
For example, my /etc/inittab currently has:
kb::kbrequest:/etc/rc/rc.reboot 2 0
# This file handles system shutdown and reboot.
# Kill all processes.
wall System is going down NOW\!
echo -n -e "\rSystem is going down: processes."
echo -n "."
echo -n ". "
# Before unmounting file systems write a reboot record to wtmp.
echo -n "wtmp "
# Swap needs to be unmounted because otherwise busy filesystems
echo -n "swap "
# Unmount file systems
echo -n "umount."
umount -a || (
echo -n "umount-retry."
umount -a || sulogin
echo -n ". "
mount -n -o remount,ro /
# Now halt or reboot.
if [ "$2" = "0" ] ; then
halt -p -f
reboot -d -f
...this will break with FUSE enabled, right? (Minor security hole by
allowing users to stop c-a-delete, where none existed before?)
I'm currently suspending by 'echo "mem" > /sys/power/state'. How
should I do that _safely_ with FUSE enabled?
If I want to get rid of nasty user in multiuser system, I do
su nastyuser 'kill -9 -1' . How do I do the equivalent with FUSE
enabled? (Without affecting other users?)
Load average was never really meaningful number, but with FUSE
enabled, users can set it to 666 without actually eating any CPU.
SIGSTOP used to work, allowing you to prevent user processes from
working while you examine them. Now SIGSTOP can be delayed for
Heck, imagine malicious user process misbehaves. Before FUSE, you
could at least attach it with gdb to look what it is doing. Now you
I really believe FUSE vs. signals needs fixing. Either that, or
updating all the manpages
man 1 kill:
- KILL 9 exit this signal may not be blocked
+ KILL 9 exit this signal may not be blocked, except by FUSE user mount
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
More information about the Containers