Feature request: Support generic session wrapper commands to start `ssh-agent` and the likes

[DarkDefender]

As per the issue title, I think it might be very useful to be able to specify a generic wrapper command that is always prepended to the session command. (It would not overwrite the xsession wapper command, just to be clear)

I have rolled out a tuigreet in a smaller office. Here we have different users using different desktop environments. To make it run smoothly and mimic gdm, I've had to hack in some code myself to have ssh-agent and dbus start automatically at login. (dbus is usually handled automatically by the wayland clients for KDE and Gnome, but it is still needed for the xorg sessions for example).

I'm just wondering if adding a generic session-wrapper command would be something that would be accepted upstream.

[apognu]

Even though I do think this should be the responsibility of another tool (PAM, systemd, etc.), we already support a wrapper mechanism for X11 sessions, so it would make sense to make it available for other kinds of sessions as well.

But, I think we should piggy-back on the system that is already in place. X11 is a special case, but we could have another --session-wrapper for other types of sessions.

In my headcanon, the two should not interact, so for your use case, you would need to define your wrapper script both in --xsession-wrapper (that would contain the startx snippet) and in --session-wrapper.

And obviously, it should be the wrapper script's responsibility to pick up the actual session command from the arguments and execute it properly.

Does that make sense and would solve your use case?

[DarkDefender]

It makes sense and seems fine to me! :)

[apognu]

I have something that works, that basically wraps the session with a script, either when it's not an X11 session, or when a freeform command is set.

I'll push this on master after I perform some testing.

[apognu]

Could you give a try to one of the compiled binaries from the dev/generic-session-wrapper branch and report if everything works as expected for your use case?

I'll also try a few of mines.

[DarkDefender]

Just a heads up, I will not have time to test this until sometime next week.

The two things I would check though is:

1. Is it possible to chain commands? IE: dbus-run-session ssh-agent startx
2. A bit unrelated, but I've patched greetd to allow auto login by reading the "last user" and "last session" file from tuigreet. Will the extra session commands be stored in the "last session" file? If not, the autologin hack I've done will not work as intended. However just to be clear, I don't think you should bend over backwards to support hack I've done. I'm just curious if it will still work.

[apognu]

The session wrapper is what it says on the tin, an executable, with its arguments, that is called with the session appended to them.

So if your wrapper is defined as /script one two and your selected session is sway, your session will be executed as /script one two sway.

Then your script can do whatever it wants with it, but tuigreet will not chain commands itself, only execute a script.

Also, the wrapper are not part of the cached values. Only the selected/entered sessions are. The wrapper is pretended to the session command as it is sent to greetd.

[DarkDefender]

Thank you so much for implementing this! Sorry for taking a month to get back to you. It seems to work as intended on my side.

From my point of view this specific feature request is now solved.