Em dom., 7 de jul. de 2024 às 06:06, Paul Sopka <psopka_at_sopka.ch> escreveu:
> Instead, I want to delegate as few functionality to them as possible. Why should I e.g. delegate the creation a directory to a binary, configured through its own config file, if it would just be one line in a script that loads the defining variables and is ran anyway?
Because, as you noticed, this will require root privileges in the
backend. And, to make it generic, complexity will again be shifted
into the service set; the common default "/run/user/${UID}", for
instance, implies serial substitution in an execline script [1] or
eval in a shell. Which by then, it will no longer be a matter of "just
2 lines of execline".
[1] See
https://skarnet.org/software/execline/multisubstitute.html
("Security" section)
https://skarnet.org/lists/skaware/2049.html.
Non daemontools-style supervisors, such as dinit (which is Turnstile's
default), also don't provide a simple "setuidgid" privilege dropper,
so they'll have little use for this functionality unless they add more
dependencies or become more error-prone.
You're making more work for yourself and the people who'd help you
maintain the service set, and making an s6 policy with more
assumptions.
>
> I experimented with Turnstile yesterday and hit major roadblocks.
>
> Here is what I have understood it does:
>
> once the user first logs in:
>
> a1) execute "${BACKEND} run ${notification_fd}" with an environment of ${USER}, ${HOME}, ...
There's two additional arguments: "$srv_dir", a folder that's
dedicated to temporary files for the service manager (which seems to
me to be the ideal place for s6-svscan's scan directory and s6-rc's
live folder¹), and "$confdir", which is the path to where the
configuration files reside (which can serve as the storage place for
an environment file).
¹From my testing, XDG_RUNTIME_DIR also works.
> This does not work, since when a2) is invoked to run the "ready" part, we do not have ${XDG_RUNTIME_DIR} anymore. I do not see how to solve this without a workaround.
>
> A possible workaround would be doubly defining XDG_RUNTIME_DIR, once in the Turnstile config and once in an env file which is sourced in the "ready" "function".
>
See `/run/service/s6rc-fdholder-filler/run` on your machine for
another solution: have 'ready' be only
```
s6-rc -l "$string" -up change default
```
and 'run' be
```
... fdmove -c 3 1 pipeline -dw { if -nt { s6-rc-init } s6-svscanctl -t
... } fdswap 3 1 s6-svscan -d3 ...
```
Instead of just s6-svscan (i. e. feed the readiness notification to
another step instead directly sending s6-svscan's notification to
turnstile).
Given dinit has the service management and service supervision layers
in the same executable, Turnstile's authors probably expect the
service management layer being up and running by the time 'run' has
notified readiness, which is possibly why they didn't bother exporting
variables in the "ready" script.
>
> I have two major issues here:
>
> A) ${BACKEND} is always invoked with the user's privileges, thus it can not create ${XDG_RUNTIME_DIR} itself.
>
> B) a2) happens without the environment, see the issue with the script.
>
>
> I think A) is a problem, since I am planning:
>
> a) to have a central user env file, preferably at /home/${USER}/.config/s6-env (${XDG_CONFIG_HOME}/s6-env), for the user to tweak his settings, e.g. ${DBUS_SESSION_BUS_ADDRESS}
>
>
> b) to have a central sysadmin env file, preferably at /etc/s6-rc/config (or similar), for the system admin to tweak the settings, e.g. the ${XDG_RUNTIME_DIR} general structure, the creation of which has to be delegated to Turnstile, since the script does not have enough permissions. This would then have to be doubly defined(once in the Turnstile config and once in the env-file)
>
Turnstile already answers item b: `/etc/turnstile/backend/*.conf` and
argument #4 of the run script. For a, nothing stops a backend from
sourcing one itself, and the runit backend is a precedent.
I'd rather document that the user must edit the desktop service
daemon's settings if they want to tweak how desktop services work.
>
> Saying "this will make it easier to implement an alternative"
> overlooks the fact that the complexity will be shifted into the
> service set and the service manager. Is it really worth it to go
> through dynamic services and events (at least, one `install -d`
> oneshot per user, and a first login/last logout event source), and
> probably other things required to make this more reliable, pretty much
> just to make a folder?
>
> I agree about the complexity shift. But I think the solution of using Turnstile just as a "notifications-system" is the best: ideally it should do the following: if ${USER} first logs in, start the system service ${USER}, if he logs out of the last instance stop the system service ${USER}.
>
> This yields the following advantages:
>
> A) The added complexity is in my opinion negligible(see my current scripts here: https://skarnet.org/lists/supervision/3123.html).
>
Your scripts are pretty close functionally to what I currently have on
my machine, but the complexity is small because they're not
configurable, and they don't export all environment variables that are
expected of a login session.
For instance, I once tried to make my equivalent set of scripts
"username-agnostic" and use s6's (the supervision suite's) built-in
instancing feature — with the username as the parameter — to spawn
user supervision trees. This was enough to make execline painful to
use correctly, and I had to switch to a shell script.
I'm currently writing a turnstile backend [1] that has a catch-all
logger and does s6-rc-init in the `run` step; it's refreshing to be
able to reasonably write it in execline.
[1]
https://paste.artixlinux.org/view/6308e776
> B) My idea gives the sysadmin and the user more control over their system.
FWIW, Turnstile also allows changing the XDG_RUNTIME_DIR and the
DBUS_SESSION_BUS_ADDRESS, and has a few more format strings than I
expected.
> (e.g. basing the location of ${XDG_RUNTIME_DIR} on a central env file where other settings are set too).
I don't think "low number of config files" is a metric worth
optimizing for, especially when the tradeoff is encoding desktop
assumptions in low-level policy.
> C) My idea allows plugging the user supervision tree directly into the system supervision tree, with the following advantages
>
> 1) Allowing to directly attach a "catch all" logger separated from the logger of Turnstile
See s6-svscan's -X option. This can be done entirely within the user's
supervision tree, and relies on the same foundation as the catch-all
logging in s6-linux-init; it just requires the scan directory to be
initialized with a catch-all logger before s6-svscan is run.
>
> 2) Keeping the chain of efficient and reliable "skarware" from the top of the tree until the last user service, without Turnstile in between.
>
As Laurent said (in regards to graphical user services, but I believe
this applies here), the tradeoff is introducing environment data
sharing and process lifetime management across unrelated process
trees, which is neither.
>
> D) Now if I want to replace Turnstile I only need to tell the Replacement the system service to start and stop. I think it is reasonable to plan that, since Turnstile is based on PAM and as Bercot said in https://skarnet.org/lists/supervision/3114.html:
>
I'm not aware of any Turnstile replacements, and given your design
goals, I think you're better off creating a small single-job PAM
module like pam_rundir [1]. Make it invoke
s6-rc/s6-instance-{create,delete}/whatever when logging in/out instead
of managing a runtime directory.
I don't think writing such a module is worth it, though. Turnstile
allows your system policy to only worry about core machine management;
your proposal will instead muddle that with stuff that's only relevant
for the desktop services.
[1]
https://gitea.artixlinux.org/artix/pam_rundir
Received on Mon Jul 08 2024 - 01:59:35 CEST