From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 881D4138716 for ; Mon, 28 Jan 2013 19:59:59 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 12E0D21C089; Mon, 28 Jan 2013 19:59:34 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 0E82021C086 for ; Mon, 28 Jan 2013 19:59:32 +0000 (UTC) Received: from [192.168.0.53] (nsg93-9-78-225-4-220.fbx.proxad.net [78.225.4.220]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: eva) by smtp.gentoo.org (Postfix) with ESMTPSA id B8CD733DA53 for ; Mon, 28 Jan 2013 19:59:31 +0000 (UTC) Message-ID: <1359403108.26344.3.camel@kanae> Subject: Re: [gentoo-dev] fcaps.eclass: bringing filesystem capabilities to the tree From: Gilles Dartiguelongue To: gentoo-dev@lists.gentoo.org Date: Mon, 28 Jan 2013 20:58:28 +0100 In-Reply-To: <201301260246.12861.vapier@gentoo.org> References: <201301251851.45021.vapier@gentoo.org> <1359159053.32487.4.camel@kanae> <201301260246.12861.vapier@gentoo.org> Organization: Gentoo Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-sue7SNKYL1yWz7s9Bqya" X-Mailer: Evolution 3.6.3 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 Mime-Version: 1.0 X-Archives-Salt: 7ff793fa-6937-453c-82a8-c10f198fc9aa X-Archives-Hash: a91428cd83db38ed65bd25d6a5e4e881 --=-sue7SNKYL1yWz7s9Bqya Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Le samedi 26 janvier 2013 =C3=A0 02:46 -0500, Mike Frysinger a =C3=A9crit : > On Friday 25 January 2013 19:10:53 Gilles Dartiguelongue wrote: > > It's not like libcap is a big dependency >=20 > true, but not everyone needs this, nor can everyone leverage it (caps). = it's=20 > a linux-centric implementation and is dependent upon filesystem support b= eing=20 > available & enabled. >=20 > that doesn't entirely justify making it a USE flag (since the code alread= y has=20 > runtime fallback logic for when the fs doesn't support things), but since= the=20 > USE is low overhead and leverages logic that already has to be there, i h= ave=20 > no problem keeping it. plus it defaults to on. hum, ok. > > and it's not like this is an > > attempt to make the system more secure by according just the privileges > > needed for apps to work as intended, right ? >=20 > mmm that's exactly what this is >=20 > > If the USE flag must stay, how is it different that current caps USE > > flag ? It applies and not just enables support but is that relevant to > > the purpose at hand ? [...] In summary, USE=3Dcaps if for stripping down from all to the bare minimum caps while USE=3Dfilecaps should allow us to provide bare minimum required capabilities from the start. If so, maybe this could be the same USE flag ? I would understand if we wanted to keep it separated to avoid potential confusion about the actual impact on packages though. --=20 Gilles Dartiguelongue Gentoo --=-sue7SNKYL1yWz7s9Bqya Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEABEKAAYFAlEG2GQACgkQ1fmVwcYIWAZCOwCg39Xm/SYpeVbrMXmr12XWyGGW c6kAn0w6S7xpT2W5gaMXATx2HhucqRxB =KO7M -----END PGP SIGNATURE----- --=-sue7SNKYL1yWz7s9Bqya--