Package: runit
Version: 2.1.2-60
Severity: wishlist
Tags: patch
Hey Lorenzo,
Would you consider adding a script to your runit package to help
runscripts benefit from my new xchpst hardening tool while falling back
to chpst-compatible options when it isn't installed, please?
xchpst works on the same principle as chpst and includes all of chpst's
options for compatibility, but adds support for Linux namespaces and
capabilities as well as other new process control features that chpst
predates.
I hope to add new features in future. I believe that runit is an
attractive service supervisor, not just for low footprint or embedded
systems, but also for desktops and servers, and that the runit ecosystem
could offer a capable non-monolithic option in those use cases without
compromising the low footprint ones! This might also preempt criticism
of systemd alternatives and improve the impression of runscripts
contributed to service packages.
The compatibility script would get installed as /usr/bin/xchpst and work
by stripping out any extended options before passing the remainder of
the command line to /usr/bin/chpst. If xchpst is installed, it sets up a
dpkg-divert and installs the proper /usr/bin/xchpst. Runscripts which
are written to benefit from extended options simply call xchpst but
indicate with a marker option ('-@') when they end.
You can find my proposed change as the head commit here:
<https://salsa.debian.org/abower/runit/-/commits/xchpst-compat>
For proof-of-concept examples of how runscripts could use this new
functionality, please see the head commit here:
<https://salsa.debian.org/abower/runit-services/-/commits/xchpst-poc>
Do you have any other thoughts on how this compatibilty could be
achieved? I'd be interested in any other options!
(One alternative would be for chpst to scan the options for the marker
before calling getopt(3) if it is invoked as xchpst - I'm happy to code
that approach up if you prefer it!)
I hope you feel this proposal is compatible with the direction you are
trying to take runit - minimal dependencies and footprint etc..
I have structured this solution so it doesn't bloat runit or runscripts
unless users and scripts opt in to take advantage. (I think the changes
would have been excessive to introduce into chpst itself and overwhelm
the code base, hence a separate tool.)
Although there would be at most minimal use of this facility in trixie,
it would be nice for the compat to be present to support third party
packages and user experimentation in the stable release ahead of forky,
and xchpst reached the archive sooner than I was expecting! For trixie
I will be focussed on consolidating the existing options and integration.
I look forward to any feedback you have, and as always thanks for all
the work on runit! I am conscious that other areas are your priority
at the moment.
Andrew
