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 1PwH6l-0001bJ-Mj for garchives@archives.gentoo.org; Sun, 06 Mar 2011 16:47:03 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 996E01C06A; Sun, 6 Mar 2011 16:46:50 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 7AFF81C066 for ; Sun, 6 Mar 2011 16:46:26 +0000 (UTC) Received: from totoro.lan.kfr (dslb-188-104-118-227.pools.arcor-ip.net [188.104.118.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: constanze) by smtp.gentoo.org (Postfix) with ESMTPSA id 546D81B4037 for ; Sun, 6 Mar 2011 16:46:25 +0000 (UTC) Date: Sun, 6 Mar 2011 17:48:04 +0100 From: Constanze Hausner To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] eclass for handling of file-based capabilities Message-ID: <20110306164804.GC14815@totoro.lan.kfr> Mail-Followup-To: gentoo-dev@lists.gentoo.org References: <20110305132421.GA8230@totoro.lan.kfr> <20110306110151.GA5990@hrair> 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: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110306110151.GA5990@hrair> User-Agent: Mutt/1.5.20 (2009-06-14) X-Archives-Salt: X-Archives-Hash: 3b63a9198dde4619bd9f18cd27f3e3a7 On 03:01 Sun 06 Mar , Brian Harring wrote: [snip] Thanks for your feedback, your remarks were correct :). I updated the eclass appropriately. > I'd take a different approach here; this code basically assumes that > the PM knows of it- note the chmod -s. The use flag protection you > tried adding, without some profile hacks, is user modifiable- meaning > users can flip it on even if the PM doesn't support it. > > Or consider that the code above is purely doing it's thing during the > install phase, specifically against whatever filesystem is used for > building- while capabilities might be able to be set there, it's > possible the final merge location won't support it. End result of > that is you'll get a setuid stripped binary merged to the > livefs lacking the caps- borkage. Or consider the inverse- the > buildroot can't do capabilities, but the livefs could. You get the > idea. > > Instead, write the code so the PM has to export a marker in some > fashion to explicitly state "yes, I can do capabilities"- I'm > specifically suggestining checking for a callback function exposed to > the env. > > If that function isn't there, then the PM can't do it- end of story. > If it is, the PM takes the args and will try to apply the > capabilities at the correct time- stripping setuid/setgid if it > succeeds. > > Please go that route; and please do not stick "portage" into the > function name, something generic we can use for a later EAPI is > better. > > Implementing it as I suggested has the nice side affect of not being > limited by PMS also, although it's an approach that still requires > planning for compatibility. I'm currently in search of a good fallback mechanism respectivly a good mechanism to deal with cap-setting in src_install. As I already said in my mail to ciaran, I'm going to give the new ideas some thought :). Cheers, constanze