supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
* Why are there 3 programs in s6 that do the same thing?
@ 2020-12-29 17:12 joaog.bastos
  2020-12-29 19:16 ` Laurent Bercot
  0 siblings, 1 reply; 3+ messages in thread
From: joaog.bastos @ 2020-12-29 17:12 UTC (permalink / raw)
  To: supervision

[-- Attachment #1: Type: text/plain, Size: 216 bytes --]

Hi.

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?

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Why are there 3 programs in s6 that do the same thing?
  2020-12-29 17:12 Why are there 3 programs in s6 that do the same thing? joaog.bastos
@ 2020-12-29 19:16 ` Laurent Bercot
  2020-12-31 22:59   ` Jonathan de Boyne Pollard
  0 siblings, 1 reply; 3+ messages in thread
From: Laurent Bercot @ 2020-12-29 19:16 UTC (permalink / raw)
  To: joaog.bastos, supervision

>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


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Why are there 3 programs in s6 that do the same thing?
  2020-12-29 19:16 ` Laurent Bercot
@ 2020-12-31 22:59   ` Jonathan de Boyne Pollard
  0 siblings, 0 replies; 3+ messages in thread
From: Jonathan de Boyne Pollard @ 2020-12-31 22:59 UTC (permalink / raw)
  To: supervision

Laurent Bercot:

> [...] direct adaptations from daemontools' setuidgid and envuidgid [...]
>

There is a similar history, and a similar spread of tools in the nosh 
toolset for roughly the same reasons.  There was a need for a split 
toolset where one could look up things in the system account database, 
do stuff (in particular stuff that obscured access to the system account 
database), and then later change the process user/group IDs.  There was 
also a need for tools that did not manipulate the user ID but only the 
group IDs.  Hence envgid, envuidgid, getuidgid, setgid-fromenv, and 
setuidgid-fromenv; with setuidgid effectively being envuidgid followed 
by setuidgid-fromenv (except that it does not touch the environment).

Uwe Ohse did the first setuidgid-fromenv tool, I believe, as a patch to 
daemontools back in 2001.  Several people have developed tools in this way.

* http://jdebp.uk./Softwares/nosh/guide/commands/setuidgid.xml

* http://jdebp.uk./Softwares/nosh/guide/commands/envuidgid.xml

* https://ohse.de/uwe/patches.html


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2020-12-31 22:59 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-12-29 17:12 Why are there 3 programs in s6 that do the same thing? joaog.bastos
2020-12-29 19:16 ` Laurent Bercot
2020-12-31 22:59   ` Jonathan de Boyne Pollard

supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/supervision

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 supervision supervision/ http://inbox.vuxu.org/supervision \
		subscribe@list.skarnet.org
	public-inbox-index supervision

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.supervision.general


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git