On Mon, 4 Jul 2016 21:43, w...@wolfsden.cz said: > 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. > 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.. 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. > 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 -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf <https://openpgp-conf.org> */ _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
