From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1PwYoB-0003Dc-0e for garchives@archives.gentoo.org; Mon, 07 Mar 2011 11:41:03 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 801F91C023; Mon, 7 Mar 2011 11:40:54 +0000 (UTC) Received: from mail-iy0-f181.google.com (mail-iy0-f181.google.com [209.85.210.181]) by pigeon.gentoo.org (Postfix) with ESMTP id C7D38E0790 for ; Mon, 7 Mar 2011 11:40:29 +0000 (UTC) Received: by iyb26 with SMTP id 26so5599010iyb.40 for ; Mon, 07 Mar 2011 03:40:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=N8m8TYsztJm9DCLDSsJuhFgntPR8Gm+6dWktUdQm2OI=; b=euEY+pQ8jOj5HJHFhyuopnykOTrC3D6RLfRvcwxfc1MUpHEfsG3hUgpIw9gZjwIX60 JFMdjNgGKBzuTCM6gcuQjFTNCFBaG3TIuJ98Krq6Qw73Y+nxsjdTGbwRLEFNArTShCPW RVCr2ehKvKeQGNrRzPLcP11Hd2E4w9nr8/+sk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=Indevpv5fEwf+FfILoZEutsqHt7FzR55UeouqK21+Ku1nprJX2PT77l66nk8rM3FzN dMZa8El992SOYz4V0rjSEedIZ96bqTCl6GAWZMW17o2Iic1Xv/A+a0Osk8RjSNGnCjPP DsnW6ACUT+w7UJNhvrBky255M5MDlEb2bCIzM= Received: by 10.231.142.24 with SMTP id o24mr2922256ibu.58.1299498028949; Mon, 07 Mar 2011 03:40:28 -0800 (PST) Received: from smtp.gmail.com (c-24-20-36-83.hsd1.or.comcast.net [24.20.36.83]) by mx.google.com with ESMTPS id 19sm544159ibx.19.2011.03.07.03.40.25 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 Mar 2011 03:40:27 -0800 (PST) Received: by smtp.gmail.com (sSMTP sendmail emulation); Mon, 07 Mar 2011 03:40:23 -0800 Date: Mon, 7 Mar 2011 03:40:23 -0800 From: Brian Harring To: mgorny@gentoo.org Cc: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] eclass for handling of file-based capabilities Message-ID: <20110307114023.GE9616@hrair> References: <20110305132421.GA8230@totoro.lan.kfr> <20110305171521.1deaf071@googlemail.com> <20110305174146.GC8230@totoro.lan.kfr> <20110305174422.4f2dffd8@googlemail.com> <20110306163428.GB14815@totoro.lan.kfr> <20110307094447.6aa04800@pomiocik.lan> 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 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3Pql8miugIZX0722" Content-Disposition: inline In-Reply-To: <20110307094447.6aa04800@pomiocik.lan> User-Agent: Mutt/1.5.20 (2009-06-14) X-Archives-Salt: X-Archives-Hash: 5177faeae0abe2d47a7c00ff09a92ef6 --3Pql8miugIZX0722 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 07, 2011 at 09:44:47AM +0100, Michaaa GGGrny wrote: > On Sun, 6 Mar 2011 17:34:29 +0100 > Constanze Hausner wrote: >=20 > > On 17:44 Sat 05 Mar , Ciaran McCreesh wrote: > > > * some filesystems don't support xattrs at all, and the package > > > manager needs to support installing to them, even if the user is > > > building on a filesystem that does support it > > > > While GSoC I was not able to come up with a good fallback mechanism. > > I'm going to give the new ideas some thought over the week and > > hopefully come up with something good :). >=20 > How about that: > 1) src_install() installs a file, like in: > /var/lib/gentoo/filecaps.d/${PF} > specifying which caps have to applied to which files, >=20 > 2) the eclass depends on an ebuild, installing a kind > of 'filecaps-apply' tool, reading information from that file and trying > to apply filecaps as necessary (and flipping setuid bits), >=20 > 3) the eclass calls that tool in pkg_postinst() to apply the caps > on the target filesystem. Exactly what benefit is derived from trying to step outside the PM for=20 this, and trying to hack up what the PM already set for permissions? General rule of thumb, the more the PM knows the better things are=20 going to be for people, and for long term compatibility. If=20 in doubt consider the improvements to user experience via=20 revdep-rebuild functionality making it into the PM; PM can actually=20 plan for rebuilds as it goes rather than potentially blowing up a=20 later build (or telling the user "go run xyz"). Consider: 1) this tool will have to grow system/user configuration for=20 overrides- something the PM could fold in easily enough into it's=20 existing capbilities. If in doubt consider FEATURES=3Dsuidctl . 2) has to be prefix aware, including understanding of deprived. This=20 can be done mind you, but like #1, the bits are already there at the=20 PM level. 3) the information recorded there is ultimately redundant when/if a=20 sane VDB format gets created; as is this info could just as easily be=20 pushed in there as a new file per CPV in the existant VDB format. 4) this requires further OOB handling for ID databases- handling that=20 could've been pushed into the PM itself (admittedly a weak point since=20 ID is already mildly screwed up here, but no point in making it=20 worse). 5) it opens up a window in every merge where setuid binaries are on=20 disk, just prior to your proposed tool getting ran. This is annoying=20 to say the least, and if the system has disabled setuid in full it's a=20 window where the binaries aren't actually usable. 6) it's slower than just having the PM do it. Specifically, the PM is=20 already transfering the content to disk, and fiddling it's bits-=20 adjusting the files modes and setting capability is something it can=20 do on creation (eliminating #5) rather than having to shell out to=20 some script. It's important to realize that the area this slows down=20 is a critical section for parallelized binpkg merging- something the=20 chrome-os folk have ran into. 6) shifting it to an external tool means the format used by the tool=20 needs standardization (rather than just being standardized via PMS) to=20 allow interop when inevitably a PM author goes to fold the=20 functionality into the PM. 7) this tool, due to it being not part of the PM, the PM has to go out=20 of it's way to protect the depgraph for- something it should already=20 be doing for itself. External, it's another hardcoded constant (or=20 addition to system set) the PM has to watch for- w/in the pm, it ought=20 to pay attention to it as is. > This should help with all the issues mentioned, including binpkg > support. Moreover, user could use the tool manually to restore/reset > filecaps if they were lost or unapplied (e.g. due to incorrect kernel > config). Every issue you've raised is addressable at the PM level- generally=20 speaking, done better at the PM level. Basically... please fix the problem at the correct location. =20 Capabilities, xattrs, etc, are not a temporary fad- they're=20 increasingly a core requirement of a linux system (thus the PM that=20 manages it). The place for this functionality is in the PM- more=20 importantly, trying to do it outside of it just makes a bigger mess=20 for PM/format authors when inevtiably it has to be pulled in. ~harring --3Pql8miugIZX0722 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) iEYEARECAAYFAk10xCcACgkQsiLx3HvNzgeW5wCfQHpPFPg19fqsAAXIg36ayB7Y i8MAoLb4c92kJ1w7jxtHWbLUzrnkiuip =EZte -----END PGP SIGNATURE----- --3Pql8miugIZX0722--