Extra socket forwarding - SUCKS

[John Runyon]

Ok, can we talk about how much of a pain it is to forward the extra socket
as a result of putting it in /run?

Like... "Note: On Systems where systemd controls the directories under
/var/run/user/<uid> it may be that the socket forwarding fails because
/var/run/user/<uid>/gnupg is deleted on logout. To workaround this you can
put gpgconf --create-socketdir in the startup script of your shell e.g.
~/.bashrc or ~/.zshrc." (https://wiki.gnupg.org/AgentForwarding)
Ok, this is just plain WRONG:
- Nothing relevant to systemd here. Nor is /var/ relevant. I don't even use
systemd. But, /run is *meant* to be cleared of files regularly, systemd or
not. (In fact, mine is a tmpfs.)
- The shell startup files are not run until AFTER the forwarding is
attempted (and FAILS). So you have to connect twice for this to actually
work.

As far as I can tell, an actual solution is creating
user-tmpfiles.d/gnupg.conf with:
d /run/user/%U 0700
d /run/user/%U/gnupg 0700

Along with a separate script:
su -c 'systemd-tmpfiles --user --create --remove' $PAM_USER

AND a PAM config to run that script (early enough that it happens before
SSH tries to create the socket):
-session        optional    pam_exec.so quiet_log
/usr/local/sbin/run-systemd-tmpfiles

(Of course, this still has the problem that it's reliant on a UID that
often changes between systems rather than a username which is, for most
people, identical across systems, but oh well)

Great fun! Good luck!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260206/1d033d9f/attachment-0001.html>