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

[Alexander Leidinger]

Am 2023-09-22 14:02, schrieb Konstantin Belousov:

On Fri, Sep 22, 2023 at 01:44:33PM +0200, Alexander Leidinger wrote:

Hi,


haven't tried if it is the same effect outside a jail.


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

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 With the gpg developer Werner Koch I tried to debug this, and we went down 79943 pinentry-tty STRU itimerval { .interval = {0, 0}, .value = {60, 0} } 79943 pinentry-tty STRU itimerval { .interval = {0, 0}, .value = {0, 0} } https://github.com/gpg/pinentry/blob/master/tty/pinentry-tty.c#L547

.zshenv -> GPG_TTY is set).


works.

So clearly, the jail is restricting the access to the pts which was
allocated on the host side instead of the jail side.


with open(). There is a mismatch.


the reason for the unexpected behavior I see?

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" -> If I do the same via ssh to this account, a new PTS is allocated and this 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 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

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.

Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    netch...@freebsd.org  : PGP 0x8F31830F9F2772BF

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.

signature.asc
Description: OpenPGP digital signature