gpg invocation on machines sharing an NFS-mounted $HOME totally broken with 2.1 (was Re: agent forwarding (via ssh)...)

Nix nix at esperi.org.uk
Mon Sep 21 14:42:28 CEST 2015


On 21 Sep 2015, nix at esperi.org.uk verbalised:

> We are now in serious trouble -- gpg-agent cannot do anything, and half
> the time it's wedged so hard only kill -9 will get rid of it.

A terrible, hacky workaround is to change *_SOCK_NAME in configure.ac to
place all the sockets in a new subdirectory of .gnupg (I called it
'sockets') and then have the boot process populate a subdirectory of
/run with per-user directories readable only by the local user and
create the sockets directory as a symlink to that. I did this just to
verify that my diagnosis was correct. It is: once the Unix-domain
sockets are on a local filesystem, and deletion of one of them does not
conflict with everyone else's instance, then the gpg-agent
extra-socket setup and the whole dance with
"ssh -o StreamLocalBindUnlink=yes -R $HOME/.gnupg/sockets/S.gpg-agent:$HOME/.gnupg/sockets/S.gpg-extra-agent"
works as intended, even when $HOME is NFS-mounted. (And indeed, the
--card-status I was using as a testcase reports 'Forbidden', indicating
that the connection is being forwarded over the agent successfully.)

But you *do* need to jump through these hoops first, to get the sockets
onto a local filesystem even if the $GNUPGHOME is NFS-shared. This is
probably more hoops than we should ask users to jump through...

-- 
NULL && (void)



More information about the Gnupg-users mailing list