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 <andrew@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!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Lorenzo,

On Mon, Mar 17, 2025 at 12:47:43AM +0100, Lorenzo wrote:

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.

Excellent, thanks!

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.

It seems to work - all in, it's a neat solution.

On Thu, 27 Feb 2025 22:52:47 +0000
Andrew Bower <andrew@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

Good to know!

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.

Yes, this needs review. We should hope that in most cases, rather than a trade-off, there is an obvious right answer (abort or continue as best
effort) so we can minimise excess complexity in configuration.

The purpose of the option check with '--exit' is to check whether the
tool understands them, rather than whether they can be applied. This is necessary because of ambiguity with getopt-style option parsing when the
option set is unknown. In fact with the file-specified options we don't
need to worry about that and it might be worth considering simply
ignoring unknown options _in the file_.

Thanks again for adding the compat,

Andrew

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Control: tags -1 - moreinfo

Hi Lorenzo,

On Mon, Mar 17, 2025 at 09:42:51PM +0000, Andrew Bower wrote:

On Mon, Mar 17, 2025 at 12:47:43AM +0100, Lorenzo wrote:

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.

It seems to work - all in, it's a neat solution.

The support for the other, unused, approaches like update-alternatives
has now been completely removed in xchpst/0.6.1-1 to keep the footprint
small on trixie users' systems, since that logic will not be needed.

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.

Yes, this needs review. We should hope that in most cases, rather than a trade-off, there is an obvious right answer (abort or continue as best effort) so we can minimise excess complexity in configuration.

The man page, xchpst(8), for xchpst/0.6.1-1 now documents the behaviour
for each option that cannot be applied in a table for users.

Thanks again for adding the compat,

Your solution seems to work well, thanks - and leads to very clear
definitions in service directories!

I look forward to seeing what hardening definitions and new service
directories runit users come up with on their trixie systems for
contributing to forky.

Andrew

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEMKYZL6LI55lncG11uqgO2W94h+kFAmfgF1IACgkQuqgO2W94 h+lgnQ//Trg2LkWTCSrGD30VrYrSB7JK93WkqkOt1XEjzQJV1zfMQeF+yPe4MVKn 4SCQYtX1l9jfeQNByWkxVA+E5SuPF0wJAk2i+H1ciVsut0LehReTLkkCXztLCeDz pdAUvCyWmp5SLwldHPlCYJAhqQjRoztiUr3ieY27DdEix++5RX3sCK2+8Zw1a7N7 QNS8euozt9zAKNp3QGpMX7DM+bhsV1bqZDHl9I09rqiMJSoL3YxFxeRRBGY62rcL x3VoJKZG2IFLjtYSU/+uvtws5LMsIqx+g+RXgPwE5ZTuZ8pM6MBvwZNe0T/PK/Mc hZJg3abFzjBNzIDE0nOWKFl/xOzlbxQT/nYmxlnswA+JeqTQu8N9rzHzrMi2kl46 5lMNfAl0GdWqgIPqfUtBSnOB44WgeVYfn5hxSXhUNqeUF/DKYzovY3fpH75wl0hg XtbFiKE72RgMMBcFhvylsQmheHNv85surljWP5MnWkV1ndv+26JRST6smtHoagKF lFzIuynXTzzJvg3e41SBmQind86rp7yivTa/wzj8OvkVeDI9Z1U8uayVZDKX+NFn JWWDqJeqwOAgd/Mv1oumS1hFT/sPf1XoyPG7WPPcclBIIny2H/LwXIY0sMl4QrQ3 J0IMRe+JvsS5mImCSIbgqDzjVgblc7GXnPljCJXEYOYnhz1g3YY=
=wDoG
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)