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

Werner Koch wk at
Wed Oct 5 19:22:11 CEST 2016

On Wed,  5 Oct 2016 17:34, dkg at said:

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

I implemented it this way to cope with the case that other software
already used a directory under this name and does not guarantee the same
permissions GnuPG needs.  I know, this is highly unlikely but after all
this socket allows access to the private keys.

Thus better fallback to the old standard name if something smelss

> 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

These are the same restrictions we have for ~/.gnupg .  Thus the move to
/run/user didn't changed anything regarding permissions.

> 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.

I think it would be okay to relax the permissions to allow group RW for
the socket file.  I am not sure about the directory.

>    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

I fact, would like to entirely get rid of sockets in the homedir.  We
still need them for compatibility reasons but in the long term they
should go away.  The logic you propose makes things even more complicate
than they are right now.

Shouldn't we discuss this based on a concrete proposal? 

For isolating gpg-agent and gpg, what about using a separate
sub-directory with permissions suitable for this?

> Alternately, is there a way to explicitly instruct gpg (and other
> clients of gpg-agent) to use a specific socket somewhere else?  We've

I have seen such a feature request / bug report.  Before we do a quick
hack here, we should evaluate the use case in more detail before we come
up with a solution.



Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 162 bytes
Desc: not available
URL: </pipermail/attachments/20161005/28610ff8/attachment.sig>

More information about the Gnupg-devel mailing list