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
