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

[Werner Koch]

On Wed,  5 Oct 2016 19:41, dkg at fifthhorseman.net said:

> is the concern here about "hijacking" like what gpg-agent did?

No, it is just a general precaution concerting private keys.  Maybe I am
a bit too over-conservative here.

> wanting to reuse code where possible, i think we might need to make the
> two decisions differently.

No.  The original idea we had for agent/gpg separation was the use
--extra-socket.  Now, that we create --extra-socket by default in the
standard socket directory, the original assumption changed because
--extra socket is not anymore configured external to GnuPG and now needs
to live with the same permissions as the standard socket.

That change, although quite convenient, made thye extra socket feature
less flexible.  Maybe we should revert this default again.

> so if the permissions on ~/.gnupg are too loose, the agent won't listen
> on a socket there -- is that right?

The effect is that gpg prints a warning and disables the execution of
external programs.  The agent was only recently fixed to restrict the
permissions on the socket file:

  commit 8127043d549a5843ea1ba2dc6da4906fc2258d53
  Date:   Wed Jun 8 16:18:02 2016 +0200

    Explicitly restrict socket permissions.
    
    * agent/gpg-agent.c (create_server_socket): Call chmod before listen.
    * scd/scdaemon.c (create_server_socket): Ditto.
    * dirmngr/dirmngr.c (main): Ditto.
    --
    
    This is just in case of a improperly set umask.  Note that a connect
    requires a write permissions.

> I'd love for them to go away as well!  how should we cope with
> non-standard homedirs, though?  I'm thinking about test suites, or

"gpgconf --create-socketdir" creates a socket directory for any homedir.
It is not done automatically so not to clutter /run/user/UID/gnupg with
lots of dedicated socket directories.

>> Shouldn't we discuss this based on a concrete proposal? 
>
> well, i tried to make a concrete proposal, though i grant that it's more
> complicated than the current situation :)

I meant a use case on how to use gnupg.

> if the parent directory is mode 0700, then any subdirectory won't be
> accessible to a different user, right?

Right, but only as long as you don't have an fd for such a subdirectory.
As long as it is not required otherwise better also restrict the
permissions of the subdirectories.

> could you point me to it?  I'd like to follow up on
> https://0xacab.org/monkeysphere/monkeysign/issues/9#note_10491

  Bug#839115: gpg and "sudo -E gpg" use different agent sockets and
  can't talk to each other

The use case is backup/restore and Josh asked for an option to tell gpg
a different agent socket.

> There are several different use cases for clients of gpg-agent to use a
> distinct agent.  Where would you like me to document them?

Frankly, I doubt that we can achieve that before 2.2 or the Debian
freeze.  Thus we should now direct our discussions to not introduce
road blockers for the future but not come up with full proposals.


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: 162 bytes
Desc: not available
URL: </pipermail/attachments/20161007/a0e14689/attachment-0001.sig>