On Tue, 2007-09-18 at 19:41 +0200, Thorsten Leemhuis wrote:
Thus I'm not even able to read from it:
$ dd if=/dev/sda3 bs=512K count=1 | strings
dd: opening `/dev/sda3': Permission denied
Life sucks, but that's how things are supposed to be in linux/unix land
as far as I know. But well, for fuse there seem to exist different rules:
$ mkdir ntfs
$ /sbin/mount.ntfs-3g /dev/sda3 ntfs/
$ touch ntfs/foo
$ ls -l ntfs/foo
-rwxrwxrwx 1 thl thl 0 18. Sep 19:27 ntfs/foo
Which brings me to my questions: Can somebody please explain why the
above it working? Does it mean that if I write my own malicious
fuse.ext3 userspace driver that I can mount each and every block-device
on my system and read or modify the files on it (all by using fuse)?
What if there is a small error in mount.ntfs-3g somewhere -- could it be
abused to destroy a partition on my system while being a ordinary user?
Thats quite weird. The way I undestand fuse is that you run the
filesystem as your user, and then that filesystem (via libfuse) spawns
fusermount to open the fuse device and attach to the mountpoint.
fusermount then passes the fd to the fuse device back the the filesystem
process (via a socket) which then handles all the requests.
Reading the data source for the filesystem (if there is any) is only
done by the filesystem process, not by the setuid fusermount helper, so
it should not be able to read /dev/sda3.
Is /sbin/mount.ntfs-3g setuid perhaps? Can you verify the uid/euid of
the ntfs mount process?