From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2525 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: "Casper Ti. Vector" Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: Update on the progress of slew development Date: Wed, 20 Mar 2019 13:14:39 +0800 Message-ID: <20190320051439.GA7636@CasperVector> References: <20190317132532.GA22622@CasperVector> <20190317153002.52c28cf7@dickeberta> <20190319124239.GA26884@CasperVector> <20190319165853.6bb9f44a@flunder> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="123240"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.11.3 (2019-02-01) To: supervision@list.skarnet.org Original-X-From: supervision-return-2115-gcsg-supervision=m.gmane.org@list.skarnet.org Wed Mar 20 06:14:54 2019 Return-path: Envelope-to: gcsg-supervision@m.gmane.org Original-Received: from alyss.skarnet.org ([95.142.172.232]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1h6TYw-000Vs7-Rt for gcsg-supervision@m.gmane.org; Wed, 20 Mar 2019 06:14:51 +0100 Original-Received: (qmail 20797 invoked by uid 89); 20 Mar 2019 05:15:14 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm Original-Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 20790 invoked from network); 20 Mar 2019 05:15:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:date:to:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=X7TG09bFx7bFtlK+r4kayVh7wfcx2mB2rx4zRtDEGbE=; b=u0p+l8xXgwfbddVTsE10hu9obfc56Dy7VYjEWAX0sM7gLRMNYlodxCXfzB+RWumPnZ FINXJItdsCqod+DAfJ3ToPO8bwkn4dHs+QXIDxd3xtn/Z75oJQ+D2Asc59Qv4uz19KKP 6Bht9XbA7YevVlDhSUsP92EIA++9AW9o641CXCF6v73wQJzLz5h6boe8tSMkai/7w9Wx rw73MQeVa8pPztV2Iw9MfLSfFr8YGMVag5hUcYcuSpoAMlS5MXbEKCySG/zBnn5QRTTZ J+3ob6HEgsArDWPLsOq0YgjO5mgYIEqqMakIFXC2G+euY2P/2lFCw2T0IvJ1yYxfqdOY HqUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:subject:message-id:mail-followup-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=X7TG09bFx7bFtlK+r4kayVh7wfcx2mB2rx4zRtDEGbE=; b=uAfIRmOxg0K4b2BRZYzqoJE1aZpLzpqZhL2XdgCxqeUwflgwX+MVfRMnG5qKvSsZ09 qwp0OJCTqlrcEy/QQZuIpFDaUntKiNrlz66IF/VePSZrPNILisYx6LB0btRFf8ngoDaT OmMbAiSMkX++N+mV6Z+lupOTvyWEyNIQ/vsZd7V2g1rpsWcr48hKYuKN4m3WLHS73xcp xF6Gz2mCmCizoZD8DNW3j5GsCTG5RNTv5fO1l9S8MdjscUA8LAQ1xe2hk1LMWcRbYD6o gLSuO8oGpbLAuspt1/bnxiZlcEtOsq4JK3e3atbidTGrr3ogJigkugzCBR5ANgu7ZF4V suwg== X-Gm-Message-State: APjAAAXH595bN+kln/eNZG/W2FoYUcLHaqyePgaUfCY9pRCNnJ6ZJoWW QttL/AaJus0YP17vlfSWbfINMgwPX4M= X-Google-Smtp-Source: APXvYqytgKwH4Fq2sDTAKJm0Gh0iWeO3Xr2+lScTTSjPiVXad96kttry5hLOehWQq6sgxNJlS0w4VA== X-Received: by 2002:a17:902:2a89:: with SMTP id j9mr6089288plb.272.1553058885154; Tue, 19 Mar 2019 22:14:45 -0700 (PDT) X-Google-Original-From: "Casper Ti. Vector" Mail-Followup-To: supervision@list.skarnet.org Content-Disposition: inline In-Reply-To: <20190319165853.6bb9f44a@flunder> Xref: news.gmane.org gmane.comp.sysutils.supervision.general:2525 Archived-At: 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