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