Hi Andrew, pushed a version of the patch with xchpst in invoke-run that uses the --file option. Hoping that it works as expected, this is what I'm comfortable to add at this stage of the release process to allow experimenting with xchpst and runscripts in Trixie.
That said, I know this is your least favorite option, I think there are still important details that need to be looked at, and I propose that we take the time to do the testing during early Trixie cycle and then define the final version of the xchpst integration. (I'm adding comments below as note to myself for further work) On Thu, 27 Feb 2025 22:52:47 +0000 Andrew Bower <and...@bower.uk> wrote: > > > I had a look at runscripts and chpst is rarely used, often with one > > option like 'chpst -uuser' or 'chpst -mNNN' or the like, so > > for instance (stealing the idea from the power-profile-daemon > > chatting we had), > > You are right. This does slightly call into question one of my core > design principles, which was to be similar in form to and compatible > with chpst - what is the point if chpst is rarely used? But we are > here now and I think xchpst does basically do its job reasonably well! I still think being compatible with chpst is added value, you never know how a user or another distro may want to use it > > [ xhcpst in invoke-run proposal, using an extra file ] > > > This is an interesting idea. Two thoughts come to mind: > > 1) Does this pollute the runit environment? An extra file in the > service directory that isn't used by runit itself? well yes, but I'm already doing this (the .meta dir) and overall I think that more features = more complexity. We could "hide and standardize" the complexity in invoke-run, or we could add complexity to the run file. There is still added complexity. Only thing that matters about the extra file IMHO is to choose the name wisely, so that we don't risk to conflict with new features of runit, in case upstream becomes active again. > > My main concern of this proposal is that it makes the standard path to > reach the crux of a runscript more complicated - invoke-run is really > useful but the more complicated and magical it is, the more opaque > everything is for runit users, I feel. (Acknowledging that the extra > complexity is intended to help people use my tool!) > > Have you seen what I have tried with a couple of runscript examples? > > https://salsa.debian.org/debian/runit-services/-/merge_requests/21/diffs > > HARDEN="xchpst --cap-bs-drop CAP_SYS_PTRACE --verbose" > $HARDEN --exit || HARDEN="" > > exec $HARDEN ##bin## > > https://salsa.debian.org/debian/runit-services/-/merge_requests/19/diffs > > HARDEN="/usr/bin/xchpst --ro-sys --private-tmp --uts-ns" > $HARDEN --exit && HARDEN="$HARDEN --verbose --" || HARDEN="" > > exec $HARDEN ##bin## $EXIMSERVICE -d > > These rely on nothing outside of themselves. They still suffer from > the problem of not being able to quote space within arguments, > although that shouldn't be a big issue. > > The '--exit' option was specifically added to return exit code 0 so > that it could be used as a test for presence of xchpst - it can also > check compatibility with the selected options. this needs to be thought carefully: a related issue is to decide what to do if one or more required hardening options are not applicable; it looks like security vs resilience tradeoff. it needs to be sorted out in xchpst first. > > If I were to summarise my thoughts on the merits of the options: > > 1) xchpst.fake: PRO: least invasive to use, CON: magic > 2) XCHPST env var CON: magic, CON: env var-based > 3) HARDEN env var CON: env var-based > > Or is that not fair? Correct, but there is a missing point; purely from maintenance point of view I see invoke-run is a PRO, as I can do a change with only one runit upload instead of editing all the runscripts (still the way the xchpst support is done need to be thought carefully otherwise this does not work) There is also another point: using invoke-run forces some standardization of runscript format; I see this one as a PRO, as it helps with long term maintenance, but other may feel strongly against this .. > > 1 & 2 both concern me in that they make xchpst 'special', which I'm > conscious of not necessarily being in the spirit of runit. Option 3 > can always be upgraded because it is self-contained. I don't rule out > any of these approaches yet!
