![]() | |||||||||||||
Messages in this thread |
> > 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. But here the decision on what to return is in the _server_. There's nothing magic about that. It's as if it was N different servers for N different clients, only more effective. > 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. I think what you call namespace invariance is basically true for all existing filesystems. There could be a filesystem which returns different directory contents based on whatever it wants, but it can't return a different "dentry" for the same name. So file/directory _content_ can be made to vary, but the namespace itself can't. > > > > 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 [well corrected :)] > > 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?) No. Fusermount checks file type and refuses the mount if there's a mismatch (and it protects against races by mounting on '.' for directories, and on '/proc/self/fd/X' for regular files). > > 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. But note, that running with the uid/gid of the user exposes the auditing script to manipulation (kill, ptrace) by the user. Running with changed fsuid/fsgid is OK though. > 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. OK, from the auditing POV, there's a slight hole in unprivileged mounts. But I don't think this is grave, since it's not so hard to hide any sensitive data from such scripts anyway (keeping data in memory, or keeping a file descriptor to an unlinked file, etc). > 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. Yes, but still this is just a difference in permission, and not a difference in namespace. > But that's not really acceptable (see previous audit case) unless FUSE > refuses to mount on non-leaf dirs. I don't think the audit case is important. It's easy to work around it manually by the sysadmin, and for the automatic case it doesn't really matter (as detailed above). 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 15:28 [W:0.166 / U:0.050 seconds] ©2003-2008 Jasper Spaans | |||||||||||||