Hi, "Michal 'hramrach' Suchanek" <[EMAIL PROTECTED]> writes:
> In the Hurd, the server should only trust ports that were given to it > when it was started (supposedly by the administrator who sets up the > root and auth servers). Later connections are considered untrusted > client connections. At least that is how I understand it. Actually, the root, auth, proc, etc. ports are passed by the parent process (or the parent filesystem in the suid case) as an argument to the `exec_exec ()' RPC. > If you run a suid passwd from a filesystem, it authenticates against the > auth the fs server was given on startup. The "real" / fs server will > trust the main auth. > > If you start passwd from your own / server you may rely on the main auth > or start your own. It will be suid in its context - your / server. > > However, the passwd from "real" / would not > work with your own auth as your auth ports cannot be verified by the > main auth. > > That way the system should be safe and give you the possibility to > divide your own rights between your processes (by using your own auth). Well, yes, that's the Unix way (UID-based) of doing it. But it's a much coarser grain that what EROS seems to allow: verification of the authenticity of a single capability. I believe that in Unix terms, "authenticity" here is equivalent to "run by root". > The question is what is an authentic server. The filesytem server should > always implement its measurement of authenticity by talking to its auth. > > If you run your own filesystem and your own auth, you cannot give away > more rights than you already posses, you can only impose more > restrictions. But you can use your own /etc/passwd that your suid passwd > program is allowed to modify. True. But maybe `auth' shouldn't be made the primary mechanism for verifying authenticity? Reasons for this is that it is coarse-grained and it should only be thought of (well, IMO) as an optional service which is part of the (optional) POSIX personality. But it's certainly more deeply rooted in the current Hurd design. Thanks, Ludovic. _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
