permissions required on /run/user/<uid>/gnupg
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Wed Oct 5 19:41:38 CEST 2016
On Wed 2016-10-05 13:22:11 -0400, Werner Koch wrote:
> On Wed, 5 Oct 2016 17:34, dkg at fifthhorseman.net 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.
is the concern here about "hijacking" like what gpg-agent did?
> Thus better fallback to the old standard name if something smelss
sorry, i don't understand whether you mean this about the decisions made
during socket creation/listening (gpg-agent's perspective) or socket
connection (gpg's perspective). Writing the e-mail earlier made me
realize that these are really two distinct sets of choices and despite
wanting to reuse code where possible, i think we might need to make the
two decisions differently.
>> 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.
so if the permissions on ~/.gnupg are too loose, the agent won't listen
on a socket there -- is that right?
>> 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.
For Linux, i believe that permissions on sockets are meaningful. iirc,
there are other unix-es that ignore permissions on unix-domain sockets,
so the directory permissions are the most important.
>> 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.
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
projects that want to use gpg with an isolated set of keys.
> The logic you propose makes things even more complicate than they are
> right now.
> 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 :)
> For isolating gpg-agent and gpg, what about using a separate
> sub-directory with permissions suitable for this?
if the parent directory is mode 0700, then any subdirectory won't be
accessible to a different user, right?
>> 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.
could you point me to it? I'd like to follow up on
> Before we do a quick hack here, we should evaluate the use case in
> more detail before we come up with a solution.
There are several different use cases for clients of gpg-agent to use a
distinct agent. Where would you like me to document them?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 930 bytes
Desc: not available
More information about the Gnupg-devel