>Wouldn't anything this does be solved by just dropping privileges of the corresponding daemons in their startup scripts?
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.
>This seems like a worse and less flexible version of B to me, I guess the only reason it is even considered is because the seat daemon does all the tracking work for you. Option B does all this does and more if I understand you correctly, thus I think B is straight up the better way.
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.
>Does anyone see any other problem arising from B?
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.
And you probably want an extra supervision tree just for seated stuff
anyway, see below.
>A) The format, do you suggest a FILENAME=content which seems easier to handle with execline and other software's(e.g. dbus) ability to write specific info to an fd which can be redirected to a file? Or do you think a file containing KEY=value, probably playing more nicely with bash and other interactive shells?
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.
>B) I think I need to make an example to explain this issue properly:
>
>I use Hyprland(https://hyprland.org/), which I start from an agetty instance. Hyprland, as any other wayland compositor/DE, sets env's. Most importantly WAYLAND_DISPLAY. It does not write those to a file. Thus I would require the user to add a script launch command to Hyprland's config which launches a script exporting the required(or all?) env's to a dir. This is unacceptable.
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?
When Hyprland isn't running, there shouldn't be any living processes
relying on WAYLAND_DISPLAY. That suggests that you want a separate
supervision tree, launched under Hyprland, to host processes that only
make sense for a seated login - just like the C case above.
I don't think that any hack to get the value of WAYLAND_DISPLAY and
store it for access by unrelated processes makes sense. Supervision
trees are cool, but they shouldn't be used to bypass normal process
hierarchies. Write down exactly what your services' lifetime should be
and design accordingly.
>Thank you for the info, I have the greatest respect for you writing only UNIX compatible software(if that's how to correctly describe it?). I am looking forward to your alternative to PAM.
Don't hold your breath - this is a longterm plan, and a considerable
amount of work.
--
Laurent
Received on Sat Jul 06 2024 - 12:40:21 CEST