No oidc-agent start when logging in with Wayland

[paulmillar]

With the release of Debian 12 (bookworm) a fresh install will default to using Wayland (instead of X11 / X.org) as its windowing environment.

Note that, as bookworm continues to support X11/X.org, computers that upgrade to bookworm (from an earlier Debian release) will continue to use X11, unless the admin explicitly switches to Wayland.

There seems to be no problem with oidc-agent under bookworm when X.org is used. However, with Wayland, the oidc-agent process is not started.

Here is the console output from a shell shortly after logging in:

paul@monkeywrench:~$ echo $XDG_CURRENT_DESKTOP
KDE
paul@monkeywrench:~$ echo $XDG_SESSION_TYPE
wayland
paul@monkeywrench:~$ pidof oidc-agent
paul@monkeywrench:~$ 

It is a relatively simple matter to start oidc-agent manually within a console. When this is done, the agent behaves as expected:

paul@monkeywrench:~$ eval `oidc-agent`
Agent pid 126481
paul@monkeywrench:~$ pidof oidc-agent
126482 126481
paul@monkeywrench:~$ oidc-add EGI-CHECKIN
Enter decryption password for account config 'EGI-CHECKIN': 
success
paul@monkeywrench:~$ oidc-token EGI-CHECKIN
eyJh[...]yXF694p6BAEXCPPOvNVsTKbw
paul@monkeywrench:~$ 

Starting oidc-agent manually suffers from the (expected) limitation that the oidc-agent environment variables are only known to that specific shell. If that agent should be accessible from processes started outside of that shell (e.g., having multiple tabs in the console) then those variables must be (manually) copied.

Starting oidc-agent as part of the X11/X.org login procedure alleviates this limitation. All child processes will share a common oidc-agent instance and inherit that agent's environment variables.

It would be helpful if some similar mechanism exists for Wayland that would allow all child processes of the login session to share a common oidc-agent instance; for example, by having all child processes inherit the oidc-agent environment variables (as currently happens with X.org).

[zachmann]

We will need to investigate this further and see what the best solution would be.

However, the following should work fairly well: Put the following line into your .bashrc:

eval `oidc-agent-service use` >/dev/null

This will start the agent the first time and on other runs, set the env var.

[marcvs]

If this works, I wonder which is the best way to solve this package wise. I.e. is there a well understood way to put it into a shell startup env? /etc/bashrc or s.th.?

[olifre]

Usually, distros patch out automatic loading of agents etc. as this should be a user decision, see for example: https://github.com/gentoo/gentoo/blob/b9e868c042eca09c4879641484ab4ba4e3198b9a/net-misc/oidc-agent/oidc-agent-5.1.0.ebuild#L65-L67 It would also be hard to cover for the various different shells and desktop environments.

FWIW, I am currently just dropping the file: https://github.com/indigo-dc/oidc-agent/blob/eddc3e8b2bb9bff13b7836cd51d65cf517f08114/config/Xsession/91oidc-agent into /etc/xdg/plasma-workspace/env/91-oidc-agent-startup.sh on my Gentoo system. That should work with the KDE/Plasma desktop environment, and should be independent of X11 / Wayland (did not test with Wayland myself yet, though).

[paulmillar]

I just tried adding that file to the /etc/xdg/plasma-workspace/env/ directory and, at least for my laptop, it seems not to start oidc-agent.

Running pidof oidc-agent doesn't show the daemon running.

[olifre]

@paulmillar Thanks for testing! That's quite strange, according to the code at https://invent.kde.org/plasma/plasma-workspace/-/blob/master/startkde/startplasma.cpp , that should work — both startplasma-wayland and startplasma-x11 should iterate through $HOME/.config/plasma-workspace/env/ and /etc/xdg/plasma-workspace/env/.

To cross-check, could you please confirm that manually running:

oidc-agent-service start-from-x

starts the agent for you, and also:

. /etc/xdg/plasma-workspace/env/91-oidc-agent-startup.sh

works (i.e. startts the agent and puts it into the environment of the running shell)?

EDIT: Main reason I'm asking is since this broke by accident in 5.2.0 (will be fixed in upcoming 5.2.1) as described in https://github.com/indigo-dc/oidc-agent/issues/593 .

[paulmillar]

Ah, I've just recreated your analysis see #596. Hey ho.

When I manually working around #593 / #596, oidc-agent is started correctly when I log in, as expected.

So, for me, the approach here closes this issue.

HOWEVER, it looks like this approach is a KDE (or plasma) specific solution. I believe it won't work for other desktop environments.

I don't know Wayland well enough to say if there's a desktop-agnostic solution for setting environments. If not, that sounds like a regression compared to X11.

[olifre]

Thanks for confirming! Sorry, I only thought of editing my initial answer later to link the reported issue.

Sadly, it seems Wayland does not offer such a mechanism (due to the different more modular concept, it seems there is no clear replacement for this approach). Gnome has listed some alternatives here: https://wiki.gnome.org/Initiatives/Wayland/SessionStart but they are all "specific" in one way or another, e.g. limited to GDM in their case or to systemd user sessions (which some distros do not use at all).

Using shell init scripts is problematic in its own ways (shell-specific, will also affect non-graphical use cases such as daemons, cronjobs and the root user).

I believe that this finally burns down to "the user has to set this up", which also allows sites to decide whether oidc-agent-service is activated system-wide or by user. So maybe documenting this cleanly is sufficient?

[paulmillar]

Thanks for confirming! Sorry, I only thought of editing my initial answer later to link the reported issue.

No problem. In any case, it's good to hear the problem has already been resolved.

Sadly, it seems Wayland does not offer such a mechanism

This definitely sounds like a regression, compared to what Xorg offers.

(due to the different more modular concept, it seems there is no clear replacement for this approach)

To me, this sounds like a case of putting the cart before the horse: the desired feature-set should dictate the implementation details, not the other way around.

Do you happen to know if anyone has already opened an issue (against Wayland) about this?

[marcvs]

Hi Guys, I'm not sure if this solution relates to your problem, but in the new 5.2.1 version of oidc-agent, clients will check a default socket to find the agent. When oidc-agent is started using oidc-agent-service this should automatically work. For now 5.2.1 is only available in https://repo.data.kit.edu, not yet in the distros.

[olifre]

This definitely sounds like a regression, compared to what Xorg offers.

I agree, but I guess that this depends on the viewpoint — Wayland does not intend to replicate what Xorg did, it's not a "graphics server", but a collection of protocols, essentially. So more of the original tasks are now delegated to parts of what is commonly called "desktop environment" (e.g. the compositor, startup scripts etc.). [This writeup}(https://pointieststick.com/2023/09/17/so-lets-talk-about-this-wayland-thing/) provides a not-overly-technical summary of the overall conceptual differences and also the "bad sides" of this still causing fragmentation today.

Do you happen to know if anyone has already opened an issue (against Wayland) about this?

I don't, probably opening a feature is a good idea. While my expectation would be that the answer is something like "it's out of scope for Wayland itself", maybe the answer will rather be something like "this should go in the XDG spec and all DEs should implement it" — or maybe that is already something which is being done.

Hi Guys, I'm not sure if this solution relates to your problem, but in the new 5.2.1 version of oidc-agent, clients will check a default socket to find the agent. When oidc-agent is started using oidc-agent-service this should automatically work.

Thanks @marcvs ! It does relate "in parts", the main problem here is that oidc-agent-service will not be started as part of the desktop session for non-X11-sessions. I pointed out an approach which works for KDE plasma, but a portable approach for any Wayland session manager would of course be better.

[marcvs]

I could look into systemd. Would that help you, or do you use non-systemd distros?

[zachmann]

In general we liked to follow ssh-agents design. Also with the XSession integration we followed their lead. So it might be worth looking into how they deal with wayland.

[marcvs]

Right; I can't use wayland atm. Input from the waylanders would be appreciated.

[zachmann]

Also generally users can make their own integration rather easy by adding

eval `oidc-agent-service use` > /dev/null

to their .bashrc. And as Marcus said with 5.2 it is not strictly necessary to set the socket env var so it can also be enough to just start it once.

[olifre]

I could look into systemd. Would that help you, or do you use non-systemd distros?

In my case, non-systemd (Gentoo :wink: ). But arguably, non-systemd users may be able to help themselves...?

In general we liked to follow ssh-agents design. Also with the XSession integration we followed their lead. So it might be worth looking into how they deal with wayland.

That's a good point. The situation appears to be somewhat messy on that end in Wayland environments, though. Some distros ship desktop environment specific environment scripts (such as Gentoo), which is for example also recommended in this openSUSE issue: https://bugzilla.opensuse.org/show_bug.cgi?id=1088564#c24 That's basically what I described here. Their claim is that other DEs such as Gnome have their own re-implementation anyways (e.g. gnome-keyring forcefully overrides whatever a session-wide SSH agent exports).

The cleanest approach is probably the systemd user unit described by ArchLinux: https://wiki.archlinux.org/title/SSH_keys#Start_ssh-agent_with_systemd_user However, this also breaks down with Gnome (again, since they override whatever is there with their own re-implementation) and does not work on non-systemd distros.

So I'm not sure there is a generic solution — for sure, there are "desktop environment specific" approaches. But it seems there is nothing working on "anything wayland" as there was in the Xorg age.