- User Since
- Mar 27 2017, 4:47 PM (220 w, 4 d)
Oct 1 2019
I believe the issue is as follows. When given the option ttyname=... pinentry will open() the given tty and that fails since it is owned by the regular user and not root; strace reports:
openat(AT_FDCWD, "/dev/pts/1", O_RDONLY) = -1 EACCES (Permission denied)
However, when not given this option, pinentry will simply write() to stdout which causes no permission problem; through sudo and the terminal this goes to /dev/pts/1.
I found a way to replicate that error with just pinentry by doing (as root):
# tty /dev/pts/1 # pinentry OK Pleased to meet you OPTION ttyname=/dev/pts/1 OK GETPIN S ERROR gtk2.open_tty_for_read 83918849 ERR 83918849 Permission denied <Pinentry>
When I remove OPTION ttyname=... there is no error.
My other terminals (xterm) are /dev/pts/1, /dev/pts/2, etc. and I can reproduce the bug in them too.
I did not (neither in my root shell nor in my user shell) but setting and exporting this environment variable does not make any difference: gpg --gen-key still fails as above. (Note that tty indeed returns /dev/pts/0 .)
Sep 30 2019
Thanks for your help investigating this.
What is weird is that pinentry supposedly detects the absence of an X session and falls back on curses. For instance, I have:
May 12 2015
This seems to work with gnupg-2.1.4. Thanks!