>s6 has three programs to set UID / GID of a process: s6-setuidgid, s6-applyuidgid and s6-envuidgid. All three of those seem to do the same thing, with some *slight* differences. Why are all three included in s6?
Those three programs don't do the same thing at all. They do *related*
things; and one of them is a wrapper around the other two.
There are two different operations at play here:
1. get the uid, gid and additional groups from the pwd/grp database
for a given username. It is a data retrieval operation with no impact
on the process state (save the storage of the information in the
environment, for later use by other programs in the chainloaded
command line). This is what s6-envuidgid does.
2. actually change the current process' uid, gid and additional groups.
There is no data retrieval here, but there is a process state change.
This is what s6-applyuidgid does.
Those two operations are distinct because you may want to set the
uid, gid and additional groups of a process to something that does not
exist in the current user database: think containers, or
cross-compiling.
Roughly speaking, s6-envuidgid reads data from the "host", but
s6-applyuidgid performs a process state change on the "target".
That said, in common cases you want to perform both operations at
once: and this is what s6-setuidgid does.
Originally, there were only s6-setuidgid and s6-envuidgid, as direct
adaptations from daemontools' setuidgid and envuidgid. However, it
soon appeared that those two programs did not encapsulate the set of
operations that s6 needs to do, and a program was needed that would
only perform the process state change. Which is why s6-applyuidgid
was added; and then, in order to save code, s6-setuidgid was rewritten
as a wrapper around s6-envuidgid and s6-applyuidgid.
--
Laurent
Received on Tue Dec 29 2020 - 19:16:15 UTC