From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) by sourceware.org (Postfix) with ESMTPS id 86AAF3858D33 for ; Wed, 19 Apr 2023 21:16:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 86AAF3858D33 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-oi1-x229.google.com with SMTP id 5614622812f47-38e692c0918so119170b6e.1 for ; Wed, 19 Apr 2023 14:16:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681938994; x=1684530994; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=yle0qftZb2RD5Ltt2uXa1aZTmgl99SeO0MH2DdF+fZY=; b=o4trGMBPbCzsNsf81iSB4xlKzEbiLaQFWbbmIDyag+NCe1p1TFY6hHLe3DVZRkGGAE U/Gn1kWncr5/gP0tPDdAJacoPDWEJW+HI73soLi6zkIoFYHn2e2qYUYE8PKhoicl7zLB fly+SB+A4FWFwt5+LyhXmp8sZt4I2bQXb8RkF7EvlSXyF4wkcSF53r3N2qjKCyGIGIKg rT2LsIkgBlcHXQ8ZGHWfUwPqEY8WukJdOq/beg16CO1ZNt09+X9F9S40JXSSDLi8jBEr R1zF1rN4mzpKV+eoSlMyUsTv/X+VImTt/zG+ydtFC626Q0iTa+rY/S+nG7ivGzCk2Yhe QfwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681938994; x=1684530994; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=yle0qftZb2RD5Ltt2uXa1aZTmgl99SeO0MH2DdF+fZY=; b=RTVdJQw84c4Gd0MChwyzFL2LCmhVC6lTat7xuXNzZZYPbeAzh5eT2rR38EHxzHN4cN GGZ0Ab7k+98qjwlq65GKz/cvhJLuYCnn/1d4HiXIGQ0KgjaDxa1sLysPl7ti+wur6xy3 wubFLU8M2sZYEZQ+l4jrbRtDkyV/Y9O1EQPN3La3mfo30zU2TAwJF5USRiz3hbBqqb03 afCmd1lKoQKCEFXKky0LMw2CNkFU4Sa7FyPlQpaHJmBaNbbebzM6784xJsz4If563Ihq 74DJV/lSs2HtZoIRXtakOKmaRdHLkhTD8ACdi2BSzHGC3DGfP4GhiqzFX+vT2RVon53K VhnQ== X-Gm-Message-State: AAQBX9esM9IlNFIqdg1ISjwNrRH0pUqQKFODZBYS1XUB6XkXxVRo+7n7 clX4GaHOV43fRr6BMZ5H+AZaAz6qGctYXo2JU+Av/k4AvGa3dg== X-Google-Smtp-Source: AKy350bSyLQ02iR2lKxIw83cNz0kXyZH/dkKtkYl9VSlKo3X29mL+6TA65vyyLFjc0VXQy4Uk0xoiFeM5c4l+bHpADI= X-Received: by 2002:a05:6808:1395:b0:38b:bed1:8a35 with SMTP id c21-20020a056808139500b0038bbed18a35mr2932707oiw.33.1681938993786; Wed, 19 Apr 2023 14:16:33 -0700 (PDT) MIME-Version: 1.0 References: <20230419160207.65988-1-bugaevc@gmail.com> <20230419160207.65988-5-bugaevc@gmail.com> In-Reply-To: From: Sergey Bugaev Date: Thu, 20 Apr 2023 00:16:22 +0300 Message-ID: Subject: Re: [RFC PATCH v2 4/7] csu: Fix standard fds' mode To: Adhemerval Zanella Netto Cc: =?UTF-8?Q?Cristian_Rodr=C3=ADguez?= , libc-alpha@sourceware.org, bug-hurd , Samuel Thibault Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Wed, Apr 19, 2023 at 11:45=E2=80=AFPM Adhemerval Zanella Netto wrote: > > I might be missing something, but why statically linked only? I don't > > see anything like that in elf/Makefile (but maybe I don't know where > > to look, please tell me!), and also the same behavior is certainly > > exhibited by dynamically linked executables too. That ls -l I posted > > above is from a dynamic executable. > > At least on Hurd, __libc_check_standard_fds is only built for !SHARED. Right, so I see that there is a separate Hurd version of this. My patch attempted to change the generic csu/check_fds.c, not the Hurd version. (Maybe there's no need to add O_IGNORE_CTTY into the generic version then). In the Hurd version all the logic is in init_standard_fds (which runs through the _hurd_fd_subinit hook) and not in __libc_check_standard_fds (), which is empty and indeed only built for !SHARED -- as the comment there says, to make sure this file is pulled in when linking against libc.a. Also the Hurd version still does check_one_fd (STDIN_FILENO, O_RDONLY); check_one_fd (STDOUT_FILENO, O_RDWR); check_one_fd (STDERR_FILENO, O_RDWR); and opens /dev/null (not /dev/full), so in any case either the generic one needs changes, or the Hurd one. If we want to port the "always fail" change onto the Hurd version, we can take advantage of the fact that on the Hurd we can truly open /dev/null with mode =3D 0 (not O_RDONLY), and it will be neither readable nor writable. > >> is this really needed now? playing silly games with this fds will alwa= ys result in silly prices. > > My understanding of this code is to enforce that on setuid program with > stdin/stdout/stderr closed any operation fail. Yes, but is that still considered desirable / a good idea? As opposed to making such operations no-op successfully (opening /dev/null with the expected mode). Sergey