Hi, On Tue, Nov 17, 2009 at 08:55:38PM +0100, olafbuddenha...@gmx.net wrote: > On Tue, Nov 17, 2009 at 01:15:59PM +0100, Carl Fredrik Hammar wrote: > > > If run by any other user then it can only recreate the intersection of > > credentials between unionfs and the client. This isn't ideal, but it > > does ensure that unionfs doesn't accidentally grant the client any new > > permissions by mistake. > > Actually I think this is just right... Whenever a client accesses a > resource through a translator, it should be restricted not only by its > own access, but also the translator's access.
Well, this naturally happens as the translator cannot possibly provide more access then it already has. > It is actually a problem that this policy is not followed whenever an > intermediate translator hands out a "real" port to another translator, > and the client reauthenticates it. (The so-called "firmlink problem".) Having a ``proxy'' do an io_restrict_auth before passing on a port has actually far reaching consequences. Remember that firmlink is only an odd use of the regular hand-off protocol when going from one translator to another, so using this policy throughout the Hurd would mean we go from a peer-to-peer authority scheme to a very hierachical one, where each step from one translator to another can only mean less authority for the client. Note also that the fact that servers return an already authenticated but restricted port that would solve the firmlink problem, rather the client must refuse to reauthenticate ports on the server's request, otherwise a malicious server could still trick the client. Does this mean that the auth server isn't needed any more? No, there is still one case this doesn't cover: to extend the clients authority, with setauth or the password server. To do this the client must reauthenticate all open ports in order for its new credentials to take effect. Also to do this properly we need to improve io_restrict_auth so it restricts the allowed operations to the intersection of the allowed operations of two sets of credentials, and not just to the operations allowed of the intersection of two sets of credentials. I'm not sure if switching to such an authority scheme is a good idea overall, but I do think it would indeed solve the firmlink problem. Regards, Fredrik
