Re: Update on the progress of slew development

["Casper Ti. Vector" <caspervector@gmail.com>]

On Tue, Mar 19, 2019 at 04:58:53PM +0100, Oliver Schad wrote:
> Exactly - it doesn't make sense for us to have for every service it's
> own logging user. So I defined a common log user.

Using separate logging users is mainly due to security reasons: though
s6-log is very reliable, reasonably more privilege separation still seem
desirable; see the example service definitions shipped with s6/s6-rc, as
well as qmail's practice of privilege separation.  And it is also easy
to do this: just put `useradd'/`adduser' invocations in post-install
hooks of the slew-related packages.

On the other hand, if you really do not want to use separate logging
users, at least do not use `nobody' (sorry for not considering this
yesterday; I have just pushed commit d5cb508b to correct this): nowadays
too many programs use `nobody' as a privilege separation user (I know
the OpenBSD people consciously avoid this, but many Linux distro
developers do not seem aware), so all these service would be in danger
if `nobody' gets compromised, especially considering that these services
are usually much easier targets for attacks than s6-log is.

> https://gitlab-2.asag.io/snippets/9

`cd /etc/slew/db' seems unnecessary as the source filename does not need
to be resolvable in $CWD of ln(1).

`s6-rc-update /etc/slew/db/compiled' is intentionally not invoked in
`lib/build.rc' because in certain conditions (eg. when some services
are renamed), the old-named service would be stopped and then the
new-named service would be started.  More seriously, since the effects
of `up' scripts for certain oneshots are reversed not in the
corresponding `down' scripts (eg. `base/fstab/pre/up' is reversed in
`init/rc.halt'), they are often not reentrant, so renaming of their
dependencies and naiively invoking `s6-rc-update /etc/slew/db/compiled'
may result in service outage that must be fixed manually.

The `-f' option of `s6-rc-update' is intended exactly for this scenario,
and the intended way to use `lib/build.rc' is:
: # Perhaps write a conversion file `conv', according to the output.
: /etc/slew/lib/build.rc main
: s6-rc-update [-f conv] /etc/slew/db/compiled
: rm -rf /etc/slew/db/old.main /etc/slew/prep.main

> killall5 didn't work at all

Fixed (provided that sysvinit killall(8) is included in the container)
in commit 3f246b20 the day before yesterday :)

> the "sync" was added just in case mounting read-only doesn't work

pkill(1), killall(1) and killall5(8) all retrieve a process list and
kill them one by one, instead of calling kill(-1, signal), so a race
condition can happen thats let some process escape the final SIGKILL.
Since pkill(1) and killall(1) use regex matching, the probability for
the race can be significantly larger.

To be 100% sure no process (except for PID 1) escapes that signal, you
can use `s6-nuke' from s6-portable-utils.  `kill -signal -- -1' should
theoretically do similar things, but kill(1) from coreutils and busybox
do not seem to behave in this way.

> emtpyenv kills the container environment, which is needed

You can replace
: /bin/emptyenv
: /bin/export PATH /usr/sbin:/usr/bin:/sbin:/bin
with something like
: /bin/importas PIA PIA
: /usr/bin/env -i PATH=/usr/sbin:/usr/bin:/sbin:/bin PIA=${PIA}

> clock adjustment doesn't work inside a container.

Then it is simpler to set `clock=()' in /etc/slew/lib/slew.rc :)

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C