From nobody Fri Sep 22 12:02:56 2023 X-Original-To: freebsd-jail@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RsWB76YPmz4tmKp for ; Fri, 22 Sep 2023 12:03:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4RsWB71j7Dz3G11 for ; Fri, 22 Sep 2023 12:03:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.17.1/8.17.1) with ESMTPS id 38MC2vfu089625 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 22 Sep 2023 15:03:00 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 38MC2vfu089625 Received: (from kostik@localhost) by tom.home (8.17.1/8.17.1/Submit) id 38MC2uYF089624; Fri, 22 Sep 2023 15:02:56 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 22 Sep 2023 15:02:56 +0300 From: Konstantin Belousov To: Alexander Leidinger Cc: FreeBSD Jail ML Subject: Re: Opening of /dev/pts/3 fails in jail (no such file), but it is visible in ls Message-ID: References: <1c9037e072f646e02082e143e42c70e0@Leidinger.net> List-Id: Discussion about FreeBSD jail(8) List-Archive: https://lists.freebsd.org/archives/freebsd-jail List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-jail@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1c9037e072f646e02082e143e42c70e0@Leidinger.net> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on tom.home X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Queue-Id: 4RsWB71j7Dz3G11 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) > 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 " > 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.