Proposal with patch: Make socket directory host dependent

[Werner Koch]

On Thu, 16 Nov 2017 13:36, rainer.perske at uni-muenster.de said:

> So the socket files must be node-specific, either by placing them into 
> a non-shared directory or by using node-specific files, so that each 
> node can run its own gpg-agent for a user.

Actually the default in 2.1 is to use a non-shared socket directry.
From the README

** Socket directory

  GnuPG uses Unix domain sockets to connect its components (on Windows
  an emulation of these sockets is used).  Depending on the type of
  the file system, it is sometimes not possible to use the GnuPG home
  directory (i.e. ~/.gnupg) as the location for the sockets.  To solve
  this problem GnuPG prefers the use of a per-user directory below the
  the /run (or /var/run) hierarchy for the the sockets.  It is thus
  suggested to create per-user directories on system or session
  startup.  For example the following snippet can be used in
  /etc/rc.local to create these directories:

      [ ! -d /run/user ] && mkdir /run/user
      awk -F: </etc/passwd '$3 >= 1000 && $3 < 65000 {print $3}' \
        | ( while read uid rest; do
              if [ ! -d "/run/user/$uid" ]; then
                mkdir /run/user/$uid
                chown $uid /run/user/$uid
                chmod 700 /run/user/$uid
              fi
            done )

Depending on the system it is /var/run.  You can use

   gpgconf --list-dirs socketdir

to check whether GnuPG is actually using it.  To check for problems you
may explicitly create the directory (which gpg does on the fly) using

   gpgconf --verbose  --create-socketdir

this uses the same code as gpg and --verbose (or --dry-run) prints
warnings if the permissions are not as expected.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20171116/1b3f6424/attachment.sig>