![]() | |||||||||||||
Messages in this thread |
On Sun, Jul 03, 2005 at 08:16:37AM +0200, Miklos Szeredi wrote: > > 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? http://clusternfs.sourceforge.net Don't ask me how this plays with the dcache. > > 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 opposite of "local" is "remote", i.e. networked filesystems: mount foo:/bar /usr/src/bar /, /usr and /usr/src are stored on a local disk. /usr/src/bar/* is not. Namespace invariance can be guaranteed for the "/usr/src" part. Not for anything below unless you control the peer. > > 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 cannot force it to remain a leaf node after the mount. So ^^^ inserted by me ok, I just remembered that any process with an open directory handle could still fchdir() underneath. I think the leaf node enforcing is possible but it is indeed a bit more complicated. (Hmm, it's a bit bizarre but could you mount FUSE on, for example, a named pipe and change it into a directory?) > I don't see why this check at mount time would make _any_ difference. It should be possible to do audits on local filesystems, e.g. by: find / /home /var -xdev .... This can be done as root but sometimes you may want to do this with the uid/gid of a specific user, for safety or for checking what the user actually can access or damage. And that won't work as expected when the user places a FUSE mount on top of his own login directory. But I don't think leaf node enforcing is required from a security point of view. This is the only thing I could come up with. IMHO The namespace argument against FUSE is weak for multiple reasons. The only variancy I see is when crossing the mount point. And that disappears once EACCES is returned when non-ptraceable processes try to cross it. But that's not really acceptable (see previous audit case) unless FUSE refuses to mount on non-leaf dirs. -- 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/ | ||||||||||||
| Last update: 2005-07-03 13:30 [from the cache] ©2003-2008 | |||||||||||||