From nobody Fri Sep 22 12:14:44 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 4RsWSc6W1Gz4tnWb for ; Fri, 22 Sep 2023 12:15:44 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature ECDSA (P-256)) (Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RsWSc55ZCz3Gmq for ; Fri, 22 Sep 2023 12:15:44 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Authentication-Results: mx1.freebsd.org; none 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1695384938; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=wKfpANbV2wOlYVHg1PuaxWSqjWISNt54ApIGMs72WU0=; b=TXf7kUjydPzuLnKS75e6Whvq3bt7q51wS/wHG9CNLq5xeB7rzmVH31j/zzYo1Dl7EYEVik lWDIEM/C6tQoj/g4J/yusu9sVBfP0iY7EFFNAhwQqT3wWgg75yoq+TYypoDdYDRqeQvrHp hjZXISiy/991k2maX51V/bkpDcWKTNOX2G0miNQYCopiycXEC5WWAcdeGkf9ncXlzZzFdb CnaMnGkqDP3xO7WGIv1VlXN3V9OGugS2tBuaHv87xoBDLQG3XW0s35y1QjB+oXqXlintYq fF9ehKc5J1LVnPmOyL86vmmaxYTzMSR8WiIhu8Hes4IhXHlu/1GSv0js7r/Llw== Date: Fri, 22 Sep 2023 14:14:44 +0200 From: Alexander Leidinger To: Konstantin Belousov Cc: FreeBSD Jail ML Subject: Re: Opening of /dev/pts/3 fails in jail (no such file), but it is visible in ls In-Reply-To: References: <1c9037e072f646e02082e143e42c70e0@Leidinger.net> Message-ID: <4944b61787c627ae604767c5c0f4d4bd@Leidinger.net> X-Sender: Alexander@Leidinger.net Organization: No organization, this is a private message. Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=_f0adeacf93a257b05a4ca6b40e46a09b"; micalg=pgp-sha256 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:34240, ipnet:2a00:1828::/32, country:DE] X-Rspamd-Queue-Id: 4RsWSc55ZCz3Gmq This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_f0adeacf93a257b05a4ca6b40e46a09b Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed 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) >> 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. 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 --=_f0adeacf93a257b05a4ca6b40e46a09b Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=833 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmUNhUQACgkQEg2wmwP4 2IZNiA//fTPIQskL7abRsWoL63TP8Lg0nek9A0TAUsc4W5i26oyzQ1gZJ0zZfq6V WcnFMbP5M7UHcWhg2o/KbzRXPhiAtrDIrGJMhW/u/PPa2i0keKkcRpHzZMnFohn7 2xelzT5hHCR/0PFmvGEvFEMWVBr62UD9Zw6kDCIGszwU/Et2988USzrfHk+RvIh4 Nv0P9vvULCsXWOCg1/fpyXgClzvU1pk0sK7lBn2P/pGxweBDT1bEcsT1pt3jGiCY ahU3NQL5y0EcOxNIf7B5mEhGGbJx3Rr+AelsRDpc2IFOUudkHxG3NLWb8szgGUox tXmXMn6m83kvItqQiN+ffU77OJ+qeIo9FlRdmxLfQTjNm1CJHqmL8WEOyir+E18R RWPgoDrr54e+/iYyUD1SaigHm7BImbX2OMeeh9XuP7Ow6gMIizmBDsjXqPHLl7R+ PDU5a9AwTrWrXstxwjfiSLIMicx2curuTKbLmUDtxqHZZTEFAv0wwX12gSCvekUl kKwMakt/mW/KYCCvN29YUaRMSlinjl/fnCStpHF7Sh6FICu+nydz79YemjZFXuuX vPPQAJZGMJIPGDzdJ1ntdCHjA+x9VDQYfWic+3LPNA27cIvmd/I5xqfEDnC50qRC XSkSkOeSTkk1Je9kIGJRAtkNlTyOtvlw8H1ol++1TsjF04/BKyQ= =CPne -----END PGP SIGNATURE----- --=_f0adeacf93a257b05a4ca6b40e46a09b--