![]() | |||||||||||||
Messages in this thread |
> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2005-07-03 08:20 [from the cache] ©2003-2008 | |||||||||||||