Opening of /dev/pts/3 fails in jail (no such file), but it is visible in ls

From: Alexander Leidinger <>
Date: Fri, 22 Sep 2023 11:44:33 UTC

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:
79943 pinentry-tty RET   write 1
  79943 pinentry-tty CALL  read(0x3,0x464697e00158,0x3ea)
  79943 pinentry-tty GIO   fd 3 read 7 bytes
  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  
  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

The file exists and I see it inside the jail:
% ll /dev/pts/3
crw--w----  1 netchild tty 0x180 22 Sep. 12:44 /dev/pts/3

The corresponding code is here:

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?


-- PGP 0x8F31830F9F2772BF  : PGP 0x8F31830F9F2772BF