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=-3.1 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE 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 823382CD39 for ; Tue, 20 Aug 2024 13:11:14 +0200 (CEST) Received: (qmail 7967 invoked by uid 550); 20 Aug 2024 11:11:10 -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 Received: (qmail 7924 invoked from network); 20 Aug 2024 11:11:09 -0000 Date: Tue, 20 Aug 2024 07:11:01 -0400 From: Rich Felker To: Gil Pedersen Cc: musl@lists.openwall.com Message-ID: <20240820111100.GX10433@brightrain.aerifal.cx> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] bug: isatty() can return wrong value On Tue, Aug 20, 2024 at 11:50:02AM +0200, Gil Pedersen wrote: > Hi, > > I found a musl related issue in systemd, where it relies on glibc specific behaviour for isatty(), which happens to work out. When using musl, it will fail in another way, causing some essential retry logic to not run. > > The error occurs when the isatty() implementation calls an ioctl() that sets the EIO error. glibc will directly forward any errors, while musl remaps it to an ENOTTY error. > > Neither behaviour are POSIX compliant. glibc sets an undocumented errno, while musl sets ENOTTY for something that is definitely a TTY. > > It seems that the correct fix is to remap the EIO to a success (1). > > See https://github.com/systemd/systemd/pull/34039 and https://sourceware.org/bugzilla/show_bug.cgi?id=32103. > > I'm not on the mailing list, so please CC any replies. 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. The right way to do this on the kernel side would have been to only return EIO for supported tty ioctls when in this state, and otherwise return ENOTTY (inappropriate ioctl for device type). 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. Rich