Hi,I'm trying to debug an issue with pinentry-tty. The reason is that I want to export a gpg secret key, but it fails when the gpg-agent tries to ask for the PW. An alternative way to export the key works, but the main way should work too. So I took the time now to dig deeper. This is inside a jail, I haven't tried if it is the same effect outside a jail.
With the gpg developer Werner Koch I tried to debug this, and we went down to do a pinentry-wrapper which calls pinentry within ktrace.
The important part is this:
---snip---
79943 pinentry-tty RET write 1
79943 pinentry-tty CALL read(0x3,0x464697e00158,0x3ea)
79943 pinentry-tty GIO fd 3 read 7 bytes
"GETPIN
"
79943 pinentry-tty RET read 7
79943 pinentry-tty CALL sigaction(SIGALRM,0x3fee6ca161d0,0)
79943 pinentry-tty RET sigaction 0
79943 pinentry-tty CALL sigaction(SIGINT,0x3fee6ca161d0,0)
79943 pinentry-tty RET sigaction 0
79943 pinentry-tty CALL
setitimer(ITIMER_REAL,0x3fee6ca16160,0x3fee6ca16140)
79943 pinentry-tty STRU itimerval { .interval = {0, 0}, .value = {60,
0} }
79943 pinentry-tty STRU itimerval { .interval = {0, 0}, .value = {0,
0} }
79943 pinentry-tty RET setitimer 0
79943 pinentry-tty CALL open(0x46469782c020,0<O_RDONLY>)
79943 pinentry-tty NAMI "/dev/pts/3"
79943 pinentry-tty RET open -1 errno 2 No such file or directory
79943 pinentry-tty CALL write(0x4,0x3fee6ca16420,0x36)
79943 pinentry-tty GIO fd 4 wrote 54 bytes
"ERR 83886179 Verarbeitung wurde abgebrochen <Pinentry>"
79943 pinentry-tty RET write 54/0x36
79943 pinentry-tty CALL write(0x4,0x3fee6dd96326,0x1)
79943 pinentry-tty GIO fd 4 wrote 1 byte
---snip---
The file exists and I see it inside the jail:
---snip---
% ll /dev/pts/3
crw--w---- 1 netchild tty 0x180 22 Sep. 12:44 /dev/pts/3
---snip---
The corresponding code is here:
https://github.com/gpg/pinentry/blob/master/tty/pinentry-tty.c#L547
The ttyname comes from the env (set via "export GPG_TTY=$(tty)") set in
my .zshenv when logging in (ssh to host, jexec into jail, "su -
netchild" -> .zshenv -> GPG_TTY is set).
If I do the same via ssh to this account, a new PTS is allocated and this works.
So clearly, the jail is restricting the access to the pts which was allocated on the host side instead of the jail side.
On one hand this is understandable, as it was not created inside the jail. On the other hand the expectation is if I see the pts inside the jail, I should be able to access it. I can see it with ls, but I can not open it with open(). There is a mismatch.
The first question which comes to my mind now is, what the bug is... is it a bug that it is visible in ls, or is it a bug that I can not open it? What is the reason for the unexpected behavior I see?
Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netch...@freebsd.org : PGP 0x8F31830F9F2772BF
signature.asc
Description: OpenPGP digital signature
