[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: On trusting its parent process

From: Ludovic Courtès
Subject: Re: On trusting its parent process
Date: Wed, 13 Jul 2005 17:46:54 +0200
User-agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux)


"Michal 'hramrach' Suchanek" <address@hidden> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]