Messages in this thread | | | Subject | Re: -mm -> 2.6.13 merge status (fuse) | From | Miklos Szeredi <> | Date | Wed, 22 Jun 2005 08:20:14 +0200 |
| |
> Not so emotional argument... > > System where users can mount their own filesystems should not be > called "Unix" any more.
It's not. It's "Linux". And anyway, sysadmin may set whatever owner/group/permissions on '/dev/fuse' to disallow or selectively allow users to be able to mount FUSE filesystems.
> It introduces new mechanism, similar to ptrace. It restricts root in > ways not seen before.
Not true. Root squash in NFS has similar effect.
> How is updatedb/locate supposed to work on system with this? How is > it going to interact with backup tools?
I assure you, that it will cause no problems whatever. These programs are able to gracefully handle errors.
> Add this to your A): "by tricking some interpretter to think script is > setuid".
How would you do that?
> > You have a choice of: 1) believe me that the current solution is > > fine > > > 2) get down and try to understand the damn thing, and then come up > > with technical arguments for/against it > > Argument is "it is **** ugly".
Yeah, that's your opinion. Mine is that it's f****** beautiful ;).
There are plenty of ugly things in Unix/Linux that you've become so accustomed to, that they no longer seem ugly. Think about the sticky bit on directories for example. That one was breaking assumptions left and right when it got introduced, but people came to accept it, because it's useful.
> Your fuse.txt explains why it is not security hole. It does not > explain why your interface is the best possible, and what alternative > ways of "not security hole" exist.
That's because I don't see any alternative. The "preventing user from tracing root" and "preventing access to user's filesysem by root" must come together. There's doesn't seem to be any other way.
BTW, thanks for reading through fuse.txt :)
Miklos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |