Re: -mm -> 2.6.13 merge status (fuse)

Miklos Szeredi
2005-06-22T07:46:53Z

> 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