Re: FUSE merging?

[Miklos Szeredi]

> After some thinking, the whole "not allowing namespace differences
> based on user id" philosophy is unenforcable and not even true sometimes
> nowadays. Think NFS: have a look at the unfsd server, you'll be surprised
> what it can do. Think any other networked file system exported by a
> machine with an unusual disk file-system underneath. IIRC ncpfs does
> this on the server based on access and thus based on uid.

Hmm, do you mean returning different directory contents based on uid?

> (hmm, I _hated_ it seeing empty directories only because I had no access
>  to anything below. Based on that I'd prefer EACCES instead of seeing an
>  empty mount stub when FUSE denies access to root or any other user.)

Well, it works that way currently, and there doesn't seem to be any
real problem with it.

> The thing is, root rules the _local_ part of the name space. So it should
> make a _huge_ difference if FUSE can fiddle with that or only with what's
> below the leaf nodes.

I don't really understand what you mean by "local".

The problem with this leaf node philosophy, is that it's not really
consistent.  You can ensure that a mountpoint is a leaf node at mount
time, but you can force it to remain a leaf node after the mount.  So
I don't see why this check at mount time would make _any_ difference.

> > > What is your opinion about replacing the ptrace check by a signal check
> > > (later on, no hurry)?
> > 
> > Maybe.  You'd still have to convince me, that signals sent to suid
> > programs are not a security problem.
> 
> google kill(2):
> 
> 	http://www.opengroup.org/onlinepubs/007908799/xsh/kill.html
> 
> It is _defined_ behavior. So, it is up to the quality of the programmer
> whether or not it results in a security problem ;-)

Ahh, right.

The info leak argument still holds, but it's pretty weak.

So if the current behavior causes a problem for sombody, and relaxing
the check from ptraceability to killability fixes it, then I'll
consider doing it.  Until then, let's keep the more secure check.

Miklos
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/