> 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 [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]
| |
 |