Date: Fri, 22 Sep 2023 14:14:44 +0200 From: Alexander Leidinger <Alexander@Leidinger.net> To: Konstantin Belousov <kostikbel@gmail.com> Cc: FreeBSD Jail ML <freebsd-jail@freebsd.org> Subject: Re: Opening of /dev/pts/3 fails in jail (no such file), but it is visible in ls Message-ID: <4944b61787c627ae604767c5c0f4d4bd@Leidinger.net> In-Reply-To: <ZQ2CcGme1wZ6zHuF@kib.kiev.ua> References: <1c9037e072f646e02082e143e42c70e0@Leidinger.net> <ZQ2CcGme1wZ6zHuF@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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<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
--=_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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4944b61787c627ae604767c5c0f4d4bd>