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

Am 2023-09-22 14:02, schrieb Konstantin Belousov:
> 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.

Everything works as technically implemented according to the rules of 
the underlying technology... and you have adapted your expectations to 
the underlying technology.

 From a human point of view who is not aware of the underlying 
technology, there is a mismatch and it does not work as expected. We 
could adapt the expectation of our users, by documenting this behavior 
in e.g. pts(4) and or jexec(8) including a way how to login to a jail 
from the host in a way which provides a good pty. Or we could adapt the 
technology, to adapt to the expectations of users. The first one is 
surely easy. The second one may be desirable.

Bye,
Alexander.

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