From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 24FC62460D for ; Tue, 26 Nov 2024 17:53:29 +0100 (CET) Received: (qmail 3930 invoked by uid 550); 26 Nov 2024 16:53:25 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com x-ms-reactions: disallow Received: (qmail 7594 invoked from network); 26 Nov 2024 10:03:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1732615428; x=1733220228; darn=lists.openwall.com; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=8kTddiROaF/WSOB8qO8PgFxpPhRvd49zi7lQLZ1VsEY=; b=d37bQaOtOcAPEGH4iZ1CLptMUd2bI7xCeD+2kTX9GGjdY0mrU49Hb+iwhDprfjHnAp /WHSn6kAri0G4jlGKVtgcXjB/oe0skqxCell5PT3pC+7jhRqUvuWKzJ/PQxuJsC5IBW5 w3DNxBVySLuE5zefOjXOkXMTgFnNRzDaTE1geMWWTzyWw867tfluJGn4PvbpZqUTLvfq Fo/dH7UGCUZ17OY8Yy2tmsgjEzp0OnFeNd0fTIVRcXGirIfesvJEsvh+KTMVxsMw/qgP VNqcLZJs8jHW1rBhsjraslnFNQ49CX3lezXk0r8EAMKDqGRM/wRtqg0MM/Dp9i9Ak53e d6/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732615428; x=1733220228; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=8kTddiROaF/WSOB8qO8PgFxpPhRvd49zi7lQLZ1VsEY=; b=GpBF3KWyJ4Djf2fEVXj4sQ9nDxUA/+5QWAYcrZO5vWNjJgyDvK9mfW8p/YzfqnDnkQ X66UNwxoydZWSa5+LQjri4q11+zAfR5s/Jx6uWCo/7FmoSTQ+sdkemcmtnC+fC0h1kE5 1xkEHNEgHGiuB+jmj/L9Ux/NoDK/Si5u95FkACtsXxI+8Aiug5YBOrUNhbWFRmZtJlTF YKYrwFRjVNBXU5LmTfJppHqj+rRfc/3sfsaURYF8SNGGJRsYN3l0bae3PdUVti9Muo/0 SnjNw5fLcBNoPmnHdTB0WHAzTsRVuTyxEHAJAYV+mYfChGM7t42lbEqW8t8nzGnk7EqP Z8dQ== X-Gm-Message-State: AOJu0YykFGBeNX0G1obrvVXRVA4WW4XR9uPCvrh/deO9eR1Si3lTWxWF z74KVaemiuaiKoVbzWjqCE5TaBXVj+QBWgSPImjUY5p65K6Ly+HS9CUDRIAs X-Gm-Gg: ASbGnctpCJbGNvBUK0/KEm6W0bCcmHQdb2lKpms3OIgraCxR739n2pL0qHrT8RhyjkF azdl0Snj0REqYrgR1r6zGzIjokDR3XJhmOdw4mpV7igFRrqFIvK/iZOy+uzLx5+pROdbOqY1CZ3 6DeClRSa+eOKuY49c+zeI4MTkSvB/yi6QNghBep3gRsomlnANVRW/fd3RSQoT/MCjTyX7gJAyAb YBex2SoxoAuAAYWT0PMgWIRXSr0aI7RZtun1xj8FUnDBUC5Z48oNgVk0GCrIQTy X-Google-Smtp-Source: AGHT+IFkxFrZyLAnArpx0LeK8rCW+kjn4pKC7QVxju9jYuK//ap2eiIRmNbYvDoWPtnRj1mXKaqxpw== X-Received: by 2002:a17:907:28c2:b0:a9a:4d1:c628 with SMTP id a640c23a62f3a-aa509bc16f2mr1218396366b.45.1732615427391; Tue, 26 Nov 2024 02:03:47 -0800 (PST) From: Gil Pedersen Message-Id: <4D107104-6B65-4A82-9662-A8392B56B744@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_575535BA-A4F0-4102-93AE-1914120414BE" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.200.121\)) Date: Tue, 26 Nov 2024 11:03:36 +0100 In-Reply-To: <20240820111100.GX10433@brightrain.aerifal.cx> Cc: musl@lists.openwall.com To: Rich Felker References: <20240820111100.GX10433@brightrain.aerifal.cx> X-Mailer: Apple Mail (2.3826.200.121) Subject: Re: [musl] bug: isatty() can return wrong value --Apple-Mail=_575535BA-A4F0-4102-93AE-1914120414BE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 20 Aug 2024, at 13.11, Rich Felker wrote: >=20 > What guarantee do we have that nothing other than a tty in this state > will return EIO for the ioctl? The implementation on the kernel side > suggests that, if they tried to put any other device in such a state > by replacing its ioctl function the same way, it would also give EIO > for these ioctls. Yeah, EIO is unconditionally signalled for any (expect TIOCSPGRP) ioctl = call when a tty is hung. While a TIOCGWINSZ ioctl call that returns EIO will very likely be a = tty, there is indeed no such guarantee. > I'm hopeful there's some good fix here where we don't have to have > either of these bad behaviors, but returning true for isatty() of a > device that is absolutely not a tty is a much worse behavior than > returning false for a device that is/was a tty when it was opened but > that's been replaced by the kernel with a defunct device. I have proposed a change to the ioctl handling in the kernel: = https://lore.kernel.org/linux-serial/20241121111506.4717-1-gpdev@gpost.dk/= If merged, the issue should be fixed going forward. /Gil= --Apple-Mail=_575535BA-A4F0-4102-93AE-1914120414BE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On 20 Aug 2024, at 13.11, Rich Felker = <dalias@libc.org> wrote:

What guarantee do we have that nothing = other than a tty in this state
will = return EIO for the ioctl? The implementation on the kernel = side
suggests that, if they = tried to put any other device in such a state
by replacing its ioctl function the same = way, it would also give EIO
for = these ioctls.

Yeah, EIO is = unconditionally signalled for any (expect TIOCSPGRP) ioctl call when a = tty is hung.
While a TIOCGWINSZ ioctl call that returns = EIO will very likely be a tty, there is indeed no such = guarantee.

I'm hopeful there's some good fix here = where we don't have to have
either = of these bad behaviors, but returning true for isatty() of a
device that is absolutely not a tty is a = much worse behavior than
returning false for a device that is/was a tty when it was = opened but
that's been replaced by = the kernel with a defunct = device.

I have proposed a = change to the ioctl handling in the kernel:


If merged, the issue should be = fixed going = forward.

/Gil
= --Apple-Mail=_575535BA-A4F0-4102-93AE-1914120414BE--