using gpg 2.1 under su or sudo

[Daniel Kahn Gillmor]

Some server administrators connect to their machines via ssh, and then
use sudo or su to switch to a different user account for administering
specific services.

For example, the qux service for example.org might be running as the
quxd user on machine.example.org; an admin might "ssh
machine.example.org" and then "su - quxd" to configure or administer the
service.

if the service administration requires the use of GnuPG with secret key
material (key generation, signing, encryption, certification, etc) and
the administrator is using "modern" GnuPG (the 2.1 branch or later) then
they're likely to have a problem because of gpg-agent.

in this situation:

 * there is no X11 session
 
 * it's unlikely that there is a user dbus session running for quxd

 * there may be no system dbus session at all
 
 * the TTY attached to the console is owned by the admin's account
   (thanks to sshd), not by quxd, so while the quxd shell (and spawned
   subprocesses) can read and write to it thanks to inheriting the file
   descriptors, the backgrounded gpg-agent has closed those file
   descriptors and its spawned pinentry cannot connect to the pty even
   to display the curses fallback.



So there appears to be no way for gpg-agent to prompt the user via any
sort of normal pinentry here.

Does anyone have a suggestion about how to facilitate this particular
workflow?

One approach is:

  echo 'allow-loopback-pinentry:0:1' | gpgconf --change-options gpg-agent
  echo pinentry-mode loopback >> ~/.gnupg/gpg.conf
  # why isn't pinentry-mode settable via gpgconf?

but this means that the user only gets prompted once for the password
(no strength checking, no confirmation), and it's also tedious setup for
this account -- it'd be better if things "just worked".

Any suggestions about what to do for this scenario?

    --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 948 bytes
Desc: not available
URL: </pipermail/attachments/20160401/16a9f79c/attachment.sig>