From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id EB933158042 for ; Mon, 11 Nov 2024 00:14:22 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E4486E08B0; Mon, 11 Nov 2024 00:14:17 +0000 (UTC) Received: from smtp.gentoo.org (dev.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id E74FBE07D4 for ; Mon, 11 Nov 2024 00:14:16 +0000 (UTC) Received: by mail-ej1-f52.google.com with SMTP id a640c23a62f3a-a9a850270e2so747997266b.0 for ; Sun, 10 Nov 2024 16:14:15 -0800 (PST) X-Gm-Message-State: AOJu0YxX02GVqnRGucXu8c3pVeQDiygNfmYFYS7dTHjZBPzskg8iOAXS ByPY2PBE0xHtT5oWJTCgMLuN62aFHBz/qBcbz2p2JDB/GwM/AXw/6GfdpRpo/UUOF+A1R5gXA4p QkJZ/Okp6TZ/Z2RAJY1AB273ej60= X-Google-Smtp-Source: AGHT+IESF0C/kFUxSCLfI5cz+nsMXpFVLp/K2qtLdorfFtpARAmQ5K6kf2zJ4fEeaEWB4N4CXwDBZ9+l7iXkTtLw3VI= X-Received: by 2002:a17:906:6a20:b0:a9e:26ad:d0a with SMTP id a640c23a62f3a-a9ef001973cmr1143958666b.58.1731284052870; Sun, 10 Nov 2024 16:14:12 -0800 (PST) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 References: <20241110215401.128418-1-floppym@gentoo.org> <20241110215401.128418-2-floppym@gentoo.org> In-Reply-To: From: Mike Gilbert Date: Sun, 10 Nov 2024 19:14:01 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [gentoo-dev] [PATCH 2/2] fcaps.eclass: make binaries readable by default To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 606dbb3c-a865-472f-9eeb-1b5035941182 X-Archives-Hash: 12428b26d95405fe38ca2d2548c34ecc On Sun, Nov 10, 2024 at 5:38=E2=80=AFPM Eli Schwartz = wrote: > > On 11/10/24 4:54 PM, Mike Gilbert wrote: > > Removing the read bit from suid binaries has questionable security > > benefit, and may cause problems for some software. > > > > Users may override FCAPS_CAPS_MODE and FCAPS_NOCAPS_MODE should they > > desire the old behavior. > > > > Bug: https://bugs.gentoo.org/938164 > > Signed-off-by: Mike Gilbert > > --- > > eclass/fcaps.eclass | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/eclass/fcaps.eclass b/eclass/fcaps.eclass > > index bf05776ba760..da4a52099396 100644 > > --- a/eclass/fcaps.eclass > > +++ b/eclass/fcaps.eclass > > @@ -70,13 +70,13 @@ esac > > # @USER_VARIABLE > > # @DESCRIPTION: > > # Mode to use when capabilities are supported. > > -: ${FCAPS_CAPS_MODE:=3D0711} > > +: ${FCAPS_CAPS_MODE:=3D0755} > > > Considering the context of the linked bug, and the change offered here, > I don't really understand the proposed solution. > > This is a very flexible variable. Way too flexible. There is no valid > use case for setting it to anything other than removing read > permissions, or preserving read permissions -- so why is it acceptable > to offer users the opportunity to define > > FCAPS_CAPS_MODE=3D"4123" > FCAPS_NOCAPS_MODE=3D"0644" > > Which is an error condition? > > If we want a user variable at all here, let it be > > : ${FCAPS_DENY_WORLD_READ:=3Dno} Good point, I can make this adjustment. > But I'm not convinced any optionality is necessary at all here. If the > expected behavior is to have read, and users are free to toggle sfperms > at the portage level, why is it necessary to make this additionally > configurable as an eclass variable? FEATURES=3D"sfperms" modifies the files during the merge phase. fcaps.eclass modifies the files in pkg_postinst, after the merge phase is complete. It does this because there is no guarantee that ${D} will reside on a filesystem that supports file-based capabilities. I don't think we want to have fcaps.eclass start looking at FEATURES since this is undefined in PMS.