Re: FUSE merging?

[Frank van Maarseveen <frankvm@frankvm.com>]

On Sat, Jul 02, 2005 at 04:49:24PM +0200, Miklos Szeredi wrote:
> > 
> > All things considered I'd still prefer forbidding FUSE mounts on non-leaf
> > dirs. For name space sanity. And it may be easier to get the whole thing
> > accepted:
> > 
> 
> But I don't think it would matter in the acceptance of the mount
> hiding patch, since that patch was not rejected on the basis of what
> FUSE would use it for, rather for the general philosophy of not
> allowing namespace differences based on user id.

That would really be a loss.

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, 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.)

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.

> > 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 ;-)

-- 
Frank
-
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/