> However, this assumes that shadowfs always has at least the permissions of > the user. If for example root wants to create a directory, he can not do it > through shadowfs if it runs as a user, he will not be able to do it through > shadowfs, right? Not that this is a big problem, as root is always able to > get at the underlying filesystems (at least theoretically).
This is not particular to shadowfs, this is an issue with any translator. The translator, a process owned by some user joebob, is deciding what fs calls to make where. So security demands that it not be able to usurp a client's privilege for those calls, as would be required for joebob's translator to create a file or directory owned by root. I would argue that even if we had a user-retries interface as Moritz suggested instead of io_restrict_auth--so the client is the only one directly exercising its privilege--it would be insecure to have it generically obey the redirection from the server. In that case, the server couldn't abuse your privilege generically to create other files or whatnot, but it could still abuse it in subtle ways like causing you to write a file other than the one you wanted written. This is the same fundamental issue as symlinks owned by joebob, which is exactly a case of the user-retries interface. But programs know about symlinks and can (and do) take explicit security precautions before following what the filesystem told them to do. It's obviously useful to have certain translator programs that root trusts to behave "properly" even when set on a node owned by a random user. You can do this trivially by making /hurd/shadowfs setuid root. What's probably more desireable is to install root-owned /servers nodes for the trusted translators, and have them all written to use fshelp_delegate. > Hmmm. Can you ever use shadowfs as a bootstrap filesystem for a new > (sub) Hurd? I've never thought about anything quite like that. The basic sub-Hurd concept is that `boot' gives you a virtual version of what real booting gives you. i.e., there is nothing to talk to but the kernel and devices. If there were any way to talk to the underlying Hurd's filesystems, the connection to it would be a new bootstrapping issue. But now that you mention it, this seems like a very useful feature! I am imagining a scenario where you have a pristine system install image in a directory on your main Hurd (e.g. from a bunch of "make install" from your native development environment), and boot a sub-Hurd whose bootstrap filesystem is a shadowfs reading from your install tree and writing to another directory on your main Hurd. In this kind of scenario, there is still no real visibility between the two Hurds. So I don't think you need to worry about the auth servers and such. The sub-Hurd's auth server is a figment of some user's imagination in the view of the main Hurd. The sub-Hurd's bootstrap shadowfs is welcome to believe whatever it likes about the uids of its users. As far as the main Hurd's filesystems are concerned, that shadowfs is just some task somewhere that has some directory ports authenticated however they were authenticated (i.e. opened by `boot' in the normal way), and it can subset that authorization with io_restrict_auth if it wants to. There is an entirely different kind of "shadowfs as the bootstrap", that I don't think you were referring to, but bears mention anyhow. That is having a bootstrap filesystem (ext2fs or whatever) that has shadowfs (or anything else) set as the translator on its root node. (Something like this might eventually be the norm.) I don't think this is handled well right now. But what it should probably do is get through the bootstrap as if there were no translator on root, as far as getting init going. Then start up the translator in the normal way to get the translated root port, and give that to init as the root port to start programs with. > > That is, each virtual directory has a cached port if the underlying > > directory has been created or an existing one used, and if there is no > > cached port you get your dotdot's port and do the lookup and dir_mkdir as > > necessary. > > But with what name, the name it was looked up under? I am worried about > things like renaming middle-directories between the lookup and the mkdir > call (worried in a confused way, because thinking about multiple filesystems > and multiple users in a shdowfs way always makes me very dizzy). Hmm, interesting question. I think the first thing to figure out is what behavior makes sense to a user for this kind of case. When you have done any writing so some COW has happened, and then the underlying directory has renames, what should it mean? We need to explore this more, but I have to go. _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
