> No, because the point is to allow users to have their own services,
> and you definitely don't want them to have access to the root
> supervision tree. So you basically have to have a separate subtree
> for each user (a privilege-dropped s6-svscan), and there are a few more
> policy questions to answer, in particular how to make sure the users
> cannot flood the root logs by misconfiguring their own logging system.
> It's doable, but not quite obvious, and it's also not quite obvious
> how to set up the system so that you don't spawn a supervision tree for
> inactive users or users who don't use the feature. So there's a little
> more work involved.
I know what you mean, and technically and in theory I fully agree with
you. As mentioned this is my currently running workaround until I
implement Turnstile.
My claim was more about a practical, applied scenario. In the terms of:
If a user is not logged in, he simply cannot control his services. So
why shall he have an entire user supervision tree of which the sole
purpose is to allow the user to control the services running with his
permission set, running at a time he is not logged in, thus not able to
control his services?
I am sure there are niche cases this solves, but I do not think they are
worth the overhead/maintenance burden of adding this on top of B).
Do you see any cases where this would actually be useful in real world
applications?
> in particular how to make sure the users
> cannot flood the root logs by misconfiguring their own logging system.
I solved that by simple read/write permissions on on the root log dir,
if you mean that.
If you are talking about flooding the uncaught logs logger of the
system. Is this not just solved by a s6-log service attached to the user
s6-svscan, acting as a catch all logger for the user tree. Since this is
inherently a system service, the user does not have the power to
sabotage this.
I am not sure whether I got you right on that.
Concerning your last point, the best I can offer for now is to have a
script, using a template dir to create the user supervision system
service. This can of course only be done by the system admin. The user
can then add whatever he wants to a previously empty bundle described in
the wiki, before invoking an "s6-user-db-update" command or similar,
invoking a script that I supply and that does the compilation and
s6-rc-update command.
B) shall solve the issue of not spawning needless supervision trees,
since it only spawns them upon login.
> It really depends on your objective. B makes a lot of sense if you
> want to treat remote logins the same way as seated logins, but there is
> also an argument to have remote logins be as simple as possible while
> not minding deploying the red carpet and a whole lot of extra services
> for seated logins, where the overhead of setting everything up will be
> negligible compared to the desktop stuff anyway.
I, again, technically agree fully, but this is in my opinion already
solving itself in practice: on a desktop system you rarely have someone
ssh'ing in. On a server system no user will ever add heavy desktop
scripts to the user service autostart, because a) he can't use them
anyway and b) they shouldn't be there(why the heck should the sysadmin
install e.g. pipewire or mpd on such a server? Packages which would be
responsible for drawing in the required user services.)
If you are actually talking about setting up s6-svscan etc., I think
that a) your software and solutions resource consumption is negligible
on modern hardware, b) I would consider user services to be a more
desktop centric system anyway.
> B is entirely legit if you make it clear that's what users get. Just to
> make sure users don't run xeyes when logging in remotely.
lmao
> The format doesn't matter if you control the readers. s6-envdir reads
> envdirs, envfile reads key=value shell-like files. Choose whatever
> format works best for you; if you need the variables to be read from a
> shell as well, the envfile format will work best. It's a question of
> convenience and preference, really.
This is why I am asking all the (more experienced) people on this list.
So that I make the best and most informed decision.
Since the only purpose is to synchronize interactive shells like
bash/zsh/..., this is probably the deciding point:
> if you need the variables to be read from a
> shell as well, the envfile format will work best.
> That means WAYLAND_DISPLAY, by design, is only be accessible to
> processes that descend from Hyprland. Why do you need to subvert it so
> unrelated processes can access it?
Apologies, I did not explain that well. It basically goes hand in hand
with what I have written here:
> One might now argue that some processes need e.g. a running wayland
> compositor, but this is the exact case "socket activation" solves. Let's
> take for example the "foot" terminal
> emulator(https://codeberg.org/dnkl/foot), which can be run as a server
> to accept "footclient" terminal emulator instances, saving memory and
> startup time. The server can only be startet once a wayland compositor
> is up and running. Using "socket activation"(fd-holding) it can be
> configured to only be started once the first instance of "footclient" is
> invoked, which can only happen once the compositor is up thus solving
> this issue completely. This should be applicable to most if not all
> software with this limitation.
And by "up and running" I mean WAYLAND_DISPLAY is set by the compositor.
I would not call the foot terminal emulator unrelated to WAYLAND_DISPLAY
and the compositor at all.
But I argue that, in case it is ran in it's server configuration, it
makes sense to supervise it, i.e. not starting it directly from the
compositor. The same can be said about notification daemons, status
bars, ...
As you have already said this is the best example for why an additional
C) would make sense. This is where my next problem arises, imagine we
now set up another supervision tree for starting it up as soon as the
compositor is there.
I can probably cleanly do this my reading from the socket seatd provides
and using s6-fdholder-retrieve, right? How could this be stopped cleanly
upon exiting the wayland compositor?
The issue on how to retrieve WAYLAND_DISPLAY arises again.
This could be solved by starting the "graphical" s6-svscan from the
compositor, e.g. Hyprland, even though the compositor is not supervised,
once it crashes it takes everything depending on it down with it anyway,
so this doesn't matter. The biggest issue is, yet again, how to stop the
services cleanly on exiting the compositor. Any ideas?
Another issue I see is that the user of the desktop system gets a third
supervision tree he has to manage. And for most of the more casual
people it is probably hard to correctly understand and use the
differences between C) and B), in the little free time they can invest
into linux.
This is why I looked at the idea of "socket activation", but now that I
think of it, this will probably fail for notification daemons, status
bars, etc.
Anyhow, you have convinced me, the third supervision is the most elegant
and clean option. I am yet again thankful for your detailed answer. I
have learned a lot and you made me aware of issues I did not see, but
have to solve.
There is another alternative I see: starting the compositor itself as a
user service. I have to think about how feasible this is. What do you think?
This brings me to the final problem which the alternative mentioned
above solves already: The user services manage a couple of things,
namely the XDG_RUNTIME_DIR and DBUS_SESSION_BUS_ADDRESS that need to be
propagated to the users login shell. Is there a more elegant way to do
this other then having the user source an env directory in his
.bash_profile?
> Don't hold your breath - this is a longterm plan, and a considerable
> amount of work.
I will not :D. I will settle with Turnstile for now (testing it today
evening), but I will happily replace it once your future solution is
finished. Your software appears perfect to me.
Thank you!
Paul
Received on Sat Jul 06 2024 - 15:09:26 CEST