[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Q: Auth server
Re: Q: Auth server
26 Oct 2001 17:04:22 +0200
Stefan Karrmann <email@example.com> writes:
> How does the exec work in detail? You have 6 parts:
> 1. Environment variable EXECSERVERS.
> 2. The user process which calls exec.
> 3. The translator which provides the executable.
> 4. The auth server.
> 5. The exec server.
> 6. The global proc server.
> In some way the user (or library) has to check if the translator is
> otherwise translators may introduce trojan horses.
I think it works like this:
1. When a setuid program is exec:d, the setuid thing will happen only
if the translator responsible for the binary has the capability to
create processes running with the uid in question.
2. When a filesystem starts a translator, it tries to start the
translator as the owner of the node on which the translator is
installed (so translators are somewhat like setuid binaries). But
again, this happens only if the parent filesystem has the
capability to start processes with that uid.
(And what happens when this is combined, and an setuid program is
installed as a translator on a node, I don't know).
The normal way of operation is that the root filesystem server runs as
root. Any translators installed on nodes owned by root will also be
started as root. A translator installed on a node owned by a user, but
located on a filesystem running as root, will be started as that user.
Same happens with setuid.
A translator or setuid binary installed on a node handled by a
non-root filesystem server will not result in any privilege elevation.
I'm not sure if such processes are started running with the uid of the
filesystem server, or with no uid:s, or not started at all.
I think the magic words when searching for this in the source is