Behavior of /dev/pts in a jail?

Hi,

I'm debugging a problem with gnupg on -current (as of Jan 20, but I  
see this problem since several months). The pinentry-tty program fails  
to ask for a PW. One of the gnupg authors found a bug which makes the  
pinentry-tty program segfault (fixed in v1.2.0), but this doesn't  
solve the problem (converts the segfault into a error output). We  
narrowed the problem down to gpg-agent not being able to see anything  
in /dev/pts and as such not being able to open my tty.

So:
  - a jail with devfs
  - login into the jail via "jexec <id> zsh" followed by "su - <user>"
  - a shell-wrapper for pinentry-tty which "ls -la /dev/pts" into a logfile
  - in the user-zsh inside the jail, I can see /dev/pts/2 (my tty) as  
being rw for me in "ls -la /dev/pts" with the same uid as my user (the  
user id inside the jail and the user id to which I ssh-ed on the  
jail-host are the same)
  - executing gpg in this same shell in a way which is supposed to ask  
for a PW results in the pinentry-wrapper being called and /dev/pts  
being completely empty in the ls output in the logfile -> no PW being  
asked
  - doing a ls of /dev/pts afterwards inside the shell still shows /dev/pts/2

Neither gpg nor gpg-agent are SUID.

This behavior surprises me. The non-root shell I use inside the jail  
sees /dev/pts/2. This shell forks gpg which forks gpg-agent which  
forks pinentry-tty. As such I would expect /dev/pts/2 being visible to  
pinentry-tty.

For me either this entry in the FS should be visible to all processes  
of this user, or to none.

What am I missing here?

Gnupg ticket: https://dev.gnupg.org/T5814
Workaround if someone has the same problem: "gpg --pinentry-mode=loopback ..."

Bye,
Alexander.

-- 
http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    netchild@FreeBSD.org  : PGP 0x8F31830F9F2772BF