Re: FUSE merging?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> > I'm not saying this is a problem, but also I don't see any
> > overwhelming reason to not allow user mounts over non-leaf
> > directories.
> 
> 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:
> 
> -	One could argue that the existing name space is extended rather than
> 	changed [for a subset of processes], what Al Viro seems to reject.
> -	The processes which cannot be ptraced/sent a signal by the mount
> 	owner are not "forced" to traverse the FUSE mount for the sake of
> 	name space invariancy, with all associated security problems: they
> 	can see everything up to the leaf node of all the usual mounts.
> 
> But put otherwise: is there a compelling reason to permit FUSE mounts on
> non-leaf nodes?

Not really.  Maybe it does have some uses, but I'm not aware of any.

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.

> Can FUSE mount on a file like NFS?

Yes.

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

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

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]
  Powered by Linux