Stefan Karrmann <[EMAIL PROTECTED]> 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 trustworthy, > 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 "secure exec". Regards, /Niels _______________________________________________ Help-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/help-hurd