www-data user cannot generate gpg key

Question

I am trying to set up passbolt on a Debian 9 KVM guest, and one of the steps is to generate a GPG key as the www-data user. Unfortunately, whenever I try to do this (by running gpg --gen-key as the www-data user), I get the following output:

...
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
gpg: agent_genkey failed: Permission denied
Key generation failed: Permission denied

The home directory for the www-data user is /var/www and the user has read-write permission there. If I run gpg --list-keys (as the www-data user) beforehand, it successfully creates the /var/www/.gnupg directory, so its not like the user doesn't have the correct permissions there.

What do I need to do in order to generate a GPG key as the www-data user?

Appendix

The env output if I log into www-data using sudo su www-data:

LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.zst=01;31:*.tzst=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.jpg=01;35:*.jpeg=01;35:*.mjpg=01;35:*.mjpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:
LANG=en_US.UTF-8
SUDO_GID=1000
USERNAME=root
SUDO_COMMAND=/bin/su www-data
USER=www-data
PWD=/home/stuart
HOME=/var/www
SUDO_USER=stuart
SUDO_UID=1000
MAIL=/var/mail/www-data
SHELL=/bin/bash
TERM=xterm-256color
SHLVL=1
LOGNAME=www-data
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
_=/usr/bin/env

The env output if I log in using sudo su - www-data

LANG=en_US.UTF-8
USER=www-data
PWD=/var/www
HOME=/var/www
MAIL=/var/mail/www-data
SHELL=/bin/bash
TERM=xterm-256color
SHLVL=1
LOGNAME=www-data
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
_=/usr/bin/env

The env output if I log in using ssh [email protected]

SSH_CONNECTION=192.168.16.155 50692 192.168.16.152 22
LANG=en_US.UTF-8
XDG_SESSION_ID=11
USER=www-data
PWD=/var/www
HOME=/var/www
SSH_CLIENT=192.168.16.155 50692 22
SSH_TTY=/dev/pts/0
MAIL=/var/mail/www-data
TERM=xterm-256color
SHELL=/bin/bash
SHLVL=1
LOGNAME=www-data
XDG_RUNTIME_DIR=/run/user/33
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
_=/usr/bin/env

Answer 1

This is a symptom of GPG's pinentry program requiring user ownership of the tty device. The failure in this example happens when pinentry would prompt for a password for the newly generated key.

From the ArchWiki:

When using pinentry, you must have the proper permissions of the terminal device (e.g. /dev/tty1) in use. However, with su (or sudo), the ownership stays with the original user, not the new one. This means that pinentry will fail with a Permission denied error, even as root.

...

The fix is to change the permissions of the device at some point before the use of pinentry (i.e. using gpg with an agent).

You can check the permissions of the terminal device in use with:

ls -l $(tty)

You will see that the file is owned by the user that first used sudo/su, not the current user.

Change the ownership of the terminal device (probably needs to be done as root; don't forget to change it back when you're done) with, e.g.:

chown www-data /dev/pts/0

Now pinentry will work correctly and the key generation process should complete successfully.

---

NB

It is not enough for the the user to be able to read/write the terminal device file, it must have user ownership set to the user attempting to use pinentry.

---

It's also possible to create a new GPG setup as any user and transfer it to any other user.

GNUPGHOME=/home/user/gpg-alt gpg --gen-key

Run through the setup like normal. Then copy the new setup to the other user and make sure to set the permissions appropriately.

# run as root
mv /home/user/gpg-alt /home/www-data/.gnupg
chown -R www-data:www-data /home/www-data/.gnupg

Answer 2

It appears that you cannot generate keys if you logged into a user account using sudo su [user]. However, if you SSH into the server as that user, e.g. ssh [email protected], then gpg --gen-key will work.