On Fri, Sep 22, 2023 at 01:44:33PM +0200, Alexander Leidinger wrote:
> 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?
Both actions behave as expected:
- visibility is governed by devfs rules, it operates on names of the
devfs nodes
- opening pty requires corresponding privileges.
So everything works as expected.
