No X pinentry when using pam-gnupg on gentoo

[mowgli]

I use pam-gnupg on gentoo and devuan. While on devuan, everything is fine, on gentoo pinentry, when started by gpg-agent started via pam-gnupg, is not able to use X. Moreover, the fallback to tty is not working too.

The only issue I see in logs is:

May  1 13:18:57 host    : pam_gnupg(wdm:setcred): helper terminated with exit code 1

What I already tried:

• Filled a bug in gentoo (https://bugs.gentoo.org/show_bug.cgi?id=774468) which got closed as invalide as pam_gnupg is not in gentoo.
• Asked on gnupg-users@gnupg.org with no outcome; even with some hints from Werner Koch.

Here some Stuff that I posted on the mailinglist:

Sure. That is all fine.
   ~> eselect pinentry list
   Available pinentry binary implementations:
     [1]   pinentry-gnome3
     [2]   pinentry-qt5 *
     [3]   pinentry-curses

From Werner Koch, I enabled pinentry-debug, here are the results:
   2021-03-05 20:03:24 gpg-agent[27031] gpg-agent (GnuPG) 2.2.25 started
   2021-03-05 20:03:48 gpg-agent[27031] SIGHUP received - re-reading configuration and flushing cache
   2021-03-05 20:03:53 gpg-agent[27031] can't connect to the PIN entry module '/usr/bin/pinentry': End of file
   2021-03-05 20:03:53 gpg-agent[27031] failed to unprotect the secret key: No pinentry
   2021-03-05 20:03:53 gpg-agent[27031] failed to read the secret key
   2021-03-05 20:03:53 gpg-agent[27031] command 'PKDECRYPT' failed: No pinentry
   2021-03-05 20:03:53 gpg-agent[27031] no device present
   2021-03-05 20:03:53 gpg-agent[27031] can't connect to the PIN entry module '/usr/bin/pinentry': End of file
   2021-03-05 20:03:53 gpg-agent[27031] smartcard decryption failed: No pinentry
   2021-03-05 20:03:53 gpg-agent[27031] command 'PKDECRYPT' failed: No pinentry

The strange thing is, that /usr/bin/pinentry is absolutely correct:
   ~> ls -l /usr/bin/pinentry
   lrwxrwxrwx 1 root root 12 29. Jan 20:37 /usr/bin/pinentry -> pinentry-qt5
   ~> ls -lL /usr/bin/pinentry
   -rwxr-xr-x 1 root root 129504 26. Jan 18:25 /usr/bin/pinentry

The Environment looks good:
   ~> gpg-connect-agent 'getinfo std_session_env' /bye
   D GPG_TTY=/dev/pts/2
   D TERM=xterm-256color
   D DISPLAY=localhost:10.0
   OK

And when logged from .xsession:
   D DISPLAY=:0
   OK

use flags:
   ~> equery u pinentry
   [ Legend : U - final flag setting for installation]
   [        : I - package is installed with flag     ]
   [ Colors : set, unset                             ]
    * Found these USE flags for app-crypt/pinentry-1.1.0-r4:
    U I
    + + caps          : Use Linux capabilities library to control privilege
    - - emacs         : Add support for GNU Emacs
    - - gnome-keyring : Enable support for storing passwords via gnome-keyring
    + + gtk           : Add support for x11-libs/gtk+ (The GIMP Toolkit)
    + + ncurses       : Add ncurses support (console display library)
    + + qt5           : Add support for the Qt 5 application and UI framework

   ~> equery u app-crypt/gnupg
   [ Legend : U - final flag setting for installation]
   [        : I - package is installed with flag     ]
   [ Colors : set, unset                             ]
    * Found these USE flags for app-crypt/gnupg-2.2.25:
    U I
    + + bzip2             : Use the bzlib compression library
    - - doc               : Add extra documentation (API, Javadoc, etc). It is recommended to enable per package instead
                            of globally
    - - ldap              : Add LDAP support (Lightweight Directory Access Protocol)
    + + nls               : Add Native Language Support (using gettext - GNU locale utilities)
    + + readline          : Enable support for libreadline, a GNU line-editing library that almost everyone wants
    - - scd-shared-access : Allow concurrent access to scdaemon by multiple apps from same user. Useful if you want to
                            use scdaemon with gnupg and for example NitroKey.
    + + smartcard         : Build scdaemon software. Enables usage of OpenPGP cards. For other type of smartcards, try
                            app-crypt/gnupg-pkcs11-scd. Bring in dev-libs/libusb as a dependency; enable scdaemon.
    + + ssl               : Add support for SSL/TLS connections (Secure Socket Layer / Transport Layer Security)
    + + tofu              : Enable support for Trust on First use trust model; requires dev-db/sqlite.
    + + tools             : Install extra tools (including gpgsplit and gpg-zip).
    + + usb               : Build direct CCID access for scdaemon; requires dev-libs/libusb.
    - - user-socket       : try a socket directory which is not removed by init manager at session end

So, the conclusion is:
- Environment seems to be fine
- pinentry is correct (and working as it work when I kill and restart
  the gpg-agent in xsession)
- The error logged is strange for me, I have no idea what went wrong

For the version, I just tried with the latest version from git. Still the same problem.

A minor additional error: pam_gnupg is installed in /lib/security while on gentoo it needs to be in /lib64/security; at least on 64 bit. Gentoo installs pam modules in both locations. I solved this issue with symlink.

[cruegge]

I'm unfortunately neither familiar with Gentoo nor xdm/wdm, and since I mostly use systemd for starting the agent, the autostarting feature is also slightly undertested.

• Can you post the relevant pam config files? If you're not using the store-only option in auth, then the helper terminated with exit code 1 error message is probably harmless, it only means that the agent could not be contacted during authentication.
• In the Gentoo ticket, you wrote that the pinentry can't read the .Xauthority. What's the error message in strace? Does your .Xauthority have a non-standard location, i.e. is $XAUTHORITY set?
• The agent has DISPLAY=localhost:10.0, which does look suspicious, and might explain why the pinentry can't start, and also cause the Xauthority issue. On the mailing list you wrote that updatestartuptty does not help. Maybe we should try to find out why. Do you use a non-default $GNUPGHOME?
• For the install location, there's a corresponding option to the configure script: ./configure --with-moduledir=/lib64/security.

[mowgli]

I try to answer your questions. I never use systemd on my systems. And this is one reason I use Devuan and Gentoo.

• My .Xauthority and .gnupg are standard. The DISPLAY to :10.0 is from ssh to the box but there is no difference to :0 when using it locally.
• For reading of the xauthority, as it is difficult to debug stuff that is (should) be started by pam. I seen straces with EPERM and others with even not trying to read that file. And I think, the later ones are the most important hints. However, the EPERM seems to be related to capabilities but there are no special capabilities set. So it is really strange for me.

Now the pam stuff.
pam file wdm

auth    substack                system-local-login
account substack                system-local-login
password        substack                system-local-login
session substack                system-local-login

pam file system-local-login

auth            include         system-login
auth            optional        pam_gnupg.so
account         include         system-login
password        include         system-login
session         include         system-login
session         optional        pam_gnupg.so

pam file system-login

auth            required        pam_shells.so
auth            required        pam_nologin.so
auth            include         system-auth
account         required        pam_access.so
account         required        pam_nologin.so
account         include         system-auth
password        include         system-auth
session         optional        pam_loginuid.so
session         required        pam_env.so envfile=/etc/profile.env
session         optional        pam_lastlog.so silent
session         include         system-auth
session         optional        pam_motd.so motd=/etc/motd
session         optional        pam_mail.so

So it is equivalent than the config on Devuan where it work.

[mowgli]

Some stuff I already posted on the mailing list:

pinentry(-qt) has no file capabilities, the process of gpg-agent has the
following:
   ~> getpcaps 27031
   27031: cap_dac_override,cap_net_admin,cap_net_raw,cap_sys_rawio,cap_sys_admin=i

And in strace I find the following:
   28441 20:23:54 capset({version=_LINUX_CAPABILITY_VERSION_3, pid=0}, {effective=1<<CAP_IPC_LOCK, permitted=1<<CAP_IPC_LOCK, inheritable=0}) = -1 EPERM (Die Operation ist nicht erlaubt)
   28441 20:23:54 capset({version=_LINUX_CAPABILITY_VERSION_3, pid=0}, {effective=0, permitted=1<<CAP_IPC_LOCK, inheritable=0}) = -1 EPERM (Die Operation ist nicht erlaubt)
   28443 20:23:54 capset({version=_LINUX_CAPABILITY_VERSION_3, pid=0}, {effective=1<<CAP_IPC_LOCK, permitted=1<<CAP_IPC_LOCK, inheritable=0}) = -1 EPERM (Die Operation ist nicht erlaubt)
   28443 20:23:54 capset({version=_LINUX_CAPABILITY_VERSION_3, pid=0}, {effective=0, permitted=1<<CAP_IPC_LOCK, inheritable=0}) = -1 EPERM (Die Operation ist nicht erlaubt)

I get the same errors when I set the capabilities to cap_ipc_lock=ep.

[mowgli]

I tried both, pinentry linked to libcap and without. No difference.

[perrin4869]

I am encountering the same problem on slackware64-current (also not using systemd). I can use the cached passphrase but once the max-cache-ttl expires, attempting to decrypt using gpg2 will result in:

❯ gpg --decrypt ~/.password-store/google.com/dotcore.co.il.gpg
gpg: encrypted with 4096-bit RSA key, ID 7E7930E005478F3C, created 2020-06-13
      "Julian Grinblat (Vae victis) <julian@dotcore.co.il>"
gpg: encrypted with 4096-bit RSA key, ID 75A99057A2B7F3DB, created 2020-05-21
      "Julian Grinblat (Vae victis) <julian@dotcore.co.il>"
gpg: public key decryption failed: No pinentry
gpg: decryption failed: No secret key

Restarting gpg-agent will restore the pinentry:

❯ gpgconf --kill gpg-agent
❯ gpg --decrypt ~/.password-store/google.com/dotcore.co.il.gpg
gpg: encrypted with 4096-bit RSA key, ID 7E7930E005478F3C, created 2020-06-13
      "Julian Grinblat (Vae victis) <julian@dotcore.co.il>"
gpg: encrypted with 4096-bit RSA key, ID 75A99057A2B7F3DB, created 2020-05-21
      "Julian Grinblat (Vae victis) <julian@dotcore.co.il>"
{encrypted content}

I didn't have problems with the pinentry before installing pam-gnupg.
Some of my setup:

❯ cat /etc/pam.d/#
#%PAM-1.0
auth            required        pam_securetty.so
# When using pam_faillock, print a message to the user if the account is
# locked. This lets the user know what is going on, but it also potentially
# gives additional information to attackers:
#auth            requisite       pam_faillock.so preauth
auth            include         system-auth
# To set a limit on failed authentications, the pam_faillock module
# can be enabled. See pam_faillock(8) for more information.
#auth            [default=die]   pam_faillock.so authfail
#auth            sufficient      pam_faillock.so authsucc
auth            include         postlogin
account         required        pam_nologin.so
account         include         system-auth
password        include         system-auth
session         include         system-auth
session         include         postlogin
session         required        pam_loginuid.so
-session        optional        pam_ck_connector.so nox11
-session        optional        pam_elogind.so
auth            optional  pam_gnupg.so store-only
session         optional  pam_gnupg.so
❯ cat ~/.gnupg/gpg-agent.conf
pinentry-program /usr/bin/pinentry-dmenu
allow-preset-passphrase
max-cache-ttl 86400
❯ cat ~/.zshrc | grep gpg
gpg-connect-agent updatestartuptty /bye >/dev/null

I will try to dig into this too