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 67E31138010 for ; Fri, 14 Sep 2012 22:28:08 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4142A21C00A; Fri, 14 Sep 2012 22:27:56 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 7441C21C001 for ; Fri, 14 Sep 2012 22:27:01 +0000 (UTC) Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: floppym) by smtp.gentoo.org (Postfix) with ESMTPSA id AE88733CEA4 for ; Fri, 14 Sep 2012 22:27:00 +0000 (UTC) Received: by weyt57 with SMTP id t57so2820970wey.40 for ; Fri, 14 Sep 2012 15:26:57 -0700 (PDT) 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 Received: by 10.180.104.197 with SMTP id gg5mr931850wib.9.1347661617835; Fri, 14 Sep 2012 15:26:57 -0700 (PDT) Received: by 10.223.100.10 with HTTP; Fri, 14 Sep 2012 15:26:57 -0700 (PDT) In-Reply-To: <50535763.9050107@gentoo.org> References: <20562.62029.425431.864386@a1i15.kph.uni-mainz.de> <50532DE2.1060908@gentoo.org> <20563.21111.934894.461651@a1i15.kph.uni-mainz.de> <50535763.9050107@gentoo.org> Date: Fri, 14 Sep 2012 18:26:57 -0400 Message-ID: Subject: Re: [gentoo-dev] bzr.eclass changes, please review From: Mike Gilbert To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: 8bf5ae62-8e00-4a80-bcc8-dc552e2a0f28 X-Archives-Hash: 5d334a284e938324f212d8d58ed5e81b On Fri, Sep 14, 2012 at 12:12 PM, Rick "Zero_Chaos" Farina wrote: > I didn't mean to pick on bzr.eclass, I think it's always wrong to do > this. And you picked out the exact reasoning I did "I'm not sure if it > would be worth the effort to compute a more accurate argument for > addwrite." I think it is worth the effort to do it right. I mean > (purposeful exaggeration here) we could save the addwrite entirely by > just "killall sandbox" or we could prevent from reoccurring by > restricting the sandbox feature. Any time you do "addwrite /" you > completely defeat the entire purpose of sandbox. It's not write (get it?). > > I'm not saying this is an emergency nor should it hold back any changes > you need to make to argue with me about it. However, if you were to do > it right that would be cool. Otherwise we could all start fixing our > sandbox issues by just doing "addwrite /" at the top of all ebuilds. > The sandbox is mostly useful to prevent build systems from messing with the live system without the developer's knowledge. It is perfectly reasonable to disable the sandbox for a single mkdir call that we have direct control over.