permissions required on /run/user/<uid>/gnupg

[Daniel Kahn Gillmor]

Hi GnuPG devs--

I've noticed that the permissions set on /run/user/<uid>/gnupg have an
effect on the choice of standard socket.

This means, for example, that if that directory is created mode 0755,
the standard socket will be created and looked for in ~/.gnupg/ instead.

Is this restriction the right choice?  The rationale for it from
gpg-agent's side is presumably that you don't want to expose the socket
to other users on the machine.  And from gpg's side, of course, it wants
to use the socket that gpg-agent is actually offering.

But consider the use case of an isolated agent, run by one user account
and deliberately exposed (on the same machine) to another user account.
In that case, the permissions shouldn't be so strict.

Would it make sense to think about the logic from the two sides
separately?  for example:

 gpg-agent startup (in default mode):

   a) if /run/user/<uid>/gnupg is owned by me and mode 0700, then listen
      on S.gpg-agent in that directory.
   b) If not, then listen on ~/.gnupg/S.gpg-agent

 gpg (and other clients of gpg-agent):

   a) look for /run/user/<uid>/gnupg/S.gpg-agent -- if it's a socket and
      i can connect to it, use it.
   b) if not, look for ~/.gnupg/S.gpg-agent -- if it's a socket and i can
      connect to it, use it.
   c) if not, spawn gpg-agent, and go back to (a)


(you'd want to add some sort of loop avoidance mechanism in the client
logic, of course)

Alternately, is there a way to explicitly instruct gpg (and other
clients of gpg-agent) to use a specific socket somewhere else?  We've
deprecated GPG_AGENT_INFO, of course, but is there a problem with the
idea of pointing gpg at a different socket if it's already present?

I'm curious to hear any thoughts on this,

    --dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 930 bytes
Desc: not available
URL: </pipermail/attachments/20161005/7a970ec2/attachment.sig>