Bug#1024342: /etc/X11/Xsession.d/90x11-common_ssh-agent: ssh-agent missing on second log-in
Package: x11-common
Version: 1:7.7+23
Severity: normal
File: /etc/X11/Xsession.d/90x11-common_ssh-agent
Dear Maintainer,
When logging out of Cinnamon and back in, I don't have ssh-agent
running any more.
Several current desktop environments persist environment variables
across logins, so that on a logout followed by a login these variables
are available. I have found code for doing so in Gnome [1] and
Cinnamon [2]. The X11 ssh-agent session startup script checks [ -z
"$SSH_AUTH_SOCK" ] as a precondition for launching ssh-agent [3]. So
when taken together, the first login will launch ssh-agent, then save
environment variables to dbus. The next session will be initialized
with these environment variables (presumably something systemd does,
haven't checked) and will therefore skip launching ssh-agent, despite
the fact that the previous agent got terminated at shutdown of the
first session.
One possible solution to this would be to replace [ -z
"$SSH_AUTH_SOCK" ] with [ ! -S "$SSH_AUTH_SOCK" ], i.e. to check that
the environment variable is not only set but actually refers to a
socket. That way, when ssh-agent for the first session terminates, the
socket will get closed and the next session will launch its own agent
despite the fact that the environment variable got persisted.
An alternative might be to also inspect SSH_AGENT_PID, and when it's
set and doesn't refer to a running process then that could also be
taken as in indication that a new agent is needed. I can't think of a
reasonable scenario that would warrant such a complex approach; I'd
think that the solution in the previous paragraph should be enough,
but if I'm missing some legitimate use case where the environment
variable would be set before the agent gets launched, then the PID
might offer a viable and even safer alternative.
Personally I'm not a fan of environment variables getting persisted in
this fashion, but given that it is default behavior in multiple
desktop environments, and probably there for a reason, I think it
makes sense to cater for it in the script. The benefits should
outweigh potential drawbacks in weird corner cases.
My current workaround, based on [4], is having this in my ~/.xsessionrc:
if [ -n "$SSH_AUTH_SOCK" ] && [ ! -S "$SSH_AUTH_SOCK" ]; then
unset SSH_AUTH_SOCK
unset SSH_AGENT_PID
fi
[1] https://salsa.debian.org/gnome-team/gnome-session/-/blob/81c88fa3485949f8c7ea12e68d07e8060d368e79/gnome-session/gsm-util.c#L544-707
[2] https://salsa.debian.org/cinnamon-team/cinnamon-session/-/blob/255fd6600dfafe131ca3247d641fdd64098f7f47/cinnamon-session/csm-util.c#L569-715
[3] https://salsa.debian.org/xorg-team/xorg/-/blob/d6af3f0a48de41f74069a8befc4fe9ca0fcd0118/debian/local/Xsession.d/90x11-common_ssh-agent#L10
[4] https://utcc.utoronto.ca/~cks/space/blog/linux/Fedora26CinnamonSSHAgent
-- System Information:
Debian Release: rodete
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages x11-common depends on:
ii lsb-base 11.2
x11-common recommends no packages.
x11-common suggests no packages.
-- no debconf information
Reply to: