Moving the agent's socket to /var/run ?

[Bertrand Jacquin]

Hi,

What about using abstract sockets ?

These sockets are the same as Unix sockets except that there's no need 
for any filesystem access. The address may be whatever string both sides 
agree upon. This can be really convenient for inter-process 
communications. Also, there is no need to take care about permissions. 
Technically it's like a Unix socket with a zero in the first byte of the 
address.

abstract namespace were introduced with Linux. See man 7 unix.

Cheers,

On 23/02/2016 15:24, Werner Koch wrote:
> Hi!
> 
> GnuPG 2.x makes extensive use of Unix domain sockets for interprocess
> communication.  For example gpg-agent is listenening for requests from
> gpg or gpgsm on the socket ~/.gnupg/S.gpg-agent .  We have received a
> couple of reports from folks who have to install GnuPG in GnuPG home
> directory with a long file name.  This does not work well with sockets
> which usually have a limit on the length of their name.  The workaround
> for this is to use the re-direction file kludge to tell the client that
> the actual socket is at some other place.  That require manual
> configuration, though.
> 
> I am also not sure whether there are really default GnuPG home
> directories which suffer from the problem.  That is a $HOME which is
> longer than about 75 bytes.
> 
> Another problem with having the socket in the home directory are
> encrypted home partition.  gpg-agent, scdaemon, and dirmngr have by
> default an open socket in ~/.gnupg and thus unmounting the partition is
> not possible without killing those processes.
> 
> What about changing the _default_ name for the sockets from, say,
> ~/.gnupg/S.gpg-agent to /var/run/user/<uid>/S.gpg-agent ?  This is
> similar to what system daemons use for their socket names and has the
> further advantage that /var/run is always locally mounted and would 
> thus
> avoid the re-direction file hack used for NFS etc.  This would only be
> done if GNUPGHOME/--homedir is not set so that it is still possible to
> run a second instance of gnupg.
> 
> What do you think?
> 
> 
> Shalom-Salam,
> 
>    Werner
> 
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel

-- 
Bertrand