Re: Behavior of /dev/pts in a jail?

On Tue, 08 Feb 2022 09:41:28 +0100
Alexander Leidinger <Alexander@leidinger.net> wrote:

> 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?


I've seen a similar problem with jails running on top of bhyve (in that
case, doing ssh wouldn't work).

The solution back then was to add ttyu* to devfs rules _before_ starting
the jail:

    devfs rule -s 3 add 3250 path "ttyu*" unhide

Not sure if what you're seeing is related, but it feels a bit like that.

See also
https://lists.freebsd.org/archives/freebsd-current/2021-August/000409.html

Cheers
Michael


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



-- 
Michael Gmelin