Change agent-socket path

[Wolf]

Greetings,
I'm in need of changing the path to the agent socket, but I cannot find
a way to do so. My problem:

gpg-agent normally runs in /run/user/1000/gnupg/S.gnu-agent , which is
completely fine. However, when building packages (archlinux, makepkg),
the building/signing is done in fakeroot environment. Therefore the
socket path default to ~/.gnupg/S.gnu-agent. Because (at least it seems
to me) in fakeroot I am root (0) and therefore don't own /run/user/1000
(1000).

What would be a good way to solve this issue?

Thanks for any help,
W.

[Eric Pruitt]

Post by Wolf
I'm in need of changing the path to the agent socket, but I cannot find
a way to do so.

For GPG 1.x, you can change this by setting the GPG_AGENT_INFO
environment variable or by using the --gpg-agent-info flag. Both of
these are documented in further detail in "man gpg." In GPG 2.x,
--gpg-agent-info is no longer used, but I think GPG_AGENT_INFO still
works; see "man gpg2" for more info.

Eric

[Werner Koch]

Post by Wolf
the building/signing is done in fakeroot environment. Therefore the
socket path default to ~/.gnupg/S.gnu-agent. Because (at least it seems
to me) in fakeroot I am root (0) and therefore don't own /run/user/1000

That is a very special case I would like to avoid an exception for this
(ie. relaxing the ownwed-by-user check).

Post by Wolf
What would be a good way to solve this issue?

You can set the envvar GNUPGHOME to a different directory and this will
then be used for the socket and all other files - assuming that you did
not create a dedicated directory below /var/user/1000/gnupg for example
with "gpgconf --create-socketdir".



Shalom-Salam,

Werner

[Wolf]

Post by Werner Koch

Post by Wolf
the building/signing is done in fakeroot environment. Therefore the
socket path default to ~/.gnupg/S.gnu-agent. Because (at least it seems
to me) in fakeroot I am root (0) and therefore don't own /run/user/1000

That is a very special case I would like to avoid an exception for this
(ie. relaxing the ownwed-by-user check).

I did some thinking about this and I must admit that I don't see why the
check is needing at all. In what situation relaxing the check would case
security issues?

Post by Werner Koch

Post by Wolf
What would be a good way to solve this issue?

You can set the envvar GNUPGHOME to a different directory and this will
then be used for the socket and all other files - assuming that you did
not create a dedicated directory below /var/user/1000/gnupg for example
with "gpgconf --create-socketdir".

So basically the "correct" solution are these two lines:

cp -r ~/.gnupg /run/user/1000/gnupg
gpg --homedir /run/user/1000/gnupg

? Since there is no way to provide the socket manually? That seems..
weird.

W.

PS: Apparently GPA is not working with 2.1.13 either (
https://bugs.archlinux.org/task/49930 ), but dunno if it's the same root
cause.

[Werner Koch]

Post by Wolf
I did some thinking about this and I must admit that I don't see why the
check is needing at all. In what situation relaxing the check would case

Such a directory may already exist with sufficient permission for any
user to create a socket. A local attacker may have created a server
listening on a socket in this directory. Now gpg connects to that
socket and a faked Pinentry catches the passphrase for the attacker.

Sure, allowing root to bypass the check is in the Unix model not a
problem. I only wonder whether this is really needed.

Post by Wolf
cp -r ~/.gnupg /run/user/1000/gnupg
gpg --homedir /run/user/1000/gnupg
? Since there is no way to provide the socket manually? That seems..

No. If you use a GNUPGHOME different from ~/.gnupg gpg will not connect
to /run/user/1000/gnupg but to /run/user/1000/gnupg/SOMEDIR/. That dir
is not created on the fly but requires that the user creates it in
advance. SOMEDIR is the hash of GNUPGHOME and gpgconf has a command to
compute that hash and create the directory.

Post by Wolf
PS: Apparently GPA is not working with 2.1.13 either (
https://bugs.archlinux.org/task/49930 ), but dunno if it's the same root

That is likley the bug fixed with GPA commit
b9efe75ab7addb2eecd8e2274ed8907b9f6a3712 .


Salam-Shalom,

Werner