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
