From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-dev+bounces-102763-garchives=archives.gentoo.org@lists.gentoo.org>
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 <garchives@archives.gentoo.org>; 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 <gentoo-dev@lists.gentoo.org>; Mon, 11 Nov 2024 00:14:16 +0000 (UTC)
Received: by mail-ej1-f52.google.com with SMTP id a640c23a62f3a-a9a850270e2so747997266b.0
for <gentoo-dev@lists.gentoo.org>; 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: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
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>
<a5a431a9-a6a3-4f71-9e66-94c85b16dca0@gentoo.org>
In-Reply-To: <a5a431a9-a6a3-4f71-9e66-94c85b16dca0@gentoo.org>
From: Mike Gilbert <floppym@gentoo.org>
Date: Sun, 10 Nov 2024 19:14:01 -0500
X-Gmail-Original-Message-ID: <CAJ0EP417Km629GM966pFu+yTQ9GdUhELWExduA+3wZ6QMMq2RQ@mail.gmail.com>
Message-ID: <CAJ0EP417Km629GM966pFu+yTQ9GdUhELWExduA+3wZ6QMMq2RQ@mail.gmail.com>
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 <eschwartz@gentoo.org>=
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 <floppym@gentoo.org>
> > ---
> > 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.