From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 8291F1396D0 for ; Fri, 22 Sep 2017 17:03:51 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1BF701FC1AC; Fri, 22 Sep 2017 17:03:46 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id BAFAA1FC1A6 for ; Fri, 22 Sep 2017 17:03:45 +0000 (UTC) Received: from professor-x (d172-218-130-128.bchsia.telus.net [172.218.130.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: dolsen) by smtp.gentoo.org (Postfix) with ESMTPSA id 9D7E233BEA7 for ; Fri, 22 Sep 2017 17:03:44 +0000 (UTC) Date: Fri, 22 Sep 2017 10:03:42 -0700 From: Brian Dolbec To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Reviving the Sandbox project Message-ID: <20170922100342.1efbea02@professor-x> In-Reply-To: References: <1506023769.15165.14.camel@gentoo.org> <1506025998.3293.1.camel@gentoo.org> <1506027262.15165.15.camel@gentoo.org> <1506028054.8561.1.camel@gentoo.org> <1506029117.15165.17.camel@gentoo.org> <1506053238.1115.0.camel@gentoo.org> <20170922125721.2fc2f243@gentoo.org> <20170922123854.179f605c@sf> X-Mailer: Claws Mail 3.15.1-dirty (GTK+ 2.24.31; x86_64-pc-linux-gnu) 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-Transfer-Encoding: 7bit X-Archives-Salt: 94f7ef1c-bcd1-40c6-8af5-ca30e5c35d9f X-Archives-Hash: 502fcc1db13eeed4b68c92d67b5f29e4 On Fri, 22 Sep 2017 15:06:49 +0000 James McMechan wrote: > On Fri, Sep 22, 2017 at 5:27 AM, Rich Freeman > wrote: > >On Fri, Sep 22, 2017 at 7:38 AM, Sergei Trofimovich > > wrote: > >> > >> Some other distros try harder to isolate build environment either > >> through chroot and/or private mount/user/network namespace that > >> contains only explicitly specified files in build environment. > >> > >> That would require more cooperation from package manager to fetch > >> list of all visible depends. > >> > > > >I definitely think this is something that would be VERY useful to > >have, because it makes build-time dependency issues almost > >impossible. > > > >However, you don't need that complete solution just to have a > >sandbox. You could simply create a container with the entire > >contents of the main filesystem, but read-only, with the exception > >of the build area. That would replicate the functionality of the > >current sandbox and would be easier than building out just the files > >specified in the dependencies. > > > >The main issue I see with making it dependency aware is performance. > >You would need to walk all the dependencies and their run-time > >dependencies, and the system set, and then individually bind-mount > >the files that belong to them read-only into the container. That > >isn't necessarily difficult, but I imagine that it would be slow. > >Walking the dependencies obviously already happens during resolution > >so that could probably be cached. You could also cache the list of > >files for the system set, and you could even maintain a snapshot of > >these that is used as the base of the container (somebody would need > >to work out the savings of doing this vs the cost of updating it > >every time a system set package changes). > > > >However, the main thing I wanted to point out is that you don't need > >a dependency-aware solution to just replace the existing sandbox. > > > >> I like clear sandbox error reporting. > > > >As far as error reporting goes, you would get kernel-level errors > >like attempting to write to a read-only bind mount, or trying to > >read a file that doesn't exist. To a portage dev it should be > >pretty obvious what is going on. You could add canned text to the > >portage error output at the end. I'm not sure how visible the > >problems would be to portage except to the degree that the build > >system makes them visible > >- it would just see make terminate with a non-zero return. > > > >I would think that containers would be almost completely bug-free > >though. The only thing I could see as an issue is some build system > >that relies on IPC with the host, network access, etc. Namespaces > >themselves are very robust, and the kernel already looks at every > >process as belonging to a set of namespaces even in the default case > >where you only have one set of namespaces on the system, so they > >don't involve different code paths/etc. > > > >-- > >Rich > > Another possibility, could be to have the sandbox be an overlayfs > not of the build directory but of the entire system starting at "/" > and stick that into the container, only CLONE_NEWNS looks to be > needed. > > A container with all writes going to the upper layer of the overlay > could be safe against even #RM -RF / and other disasters, while still > tracking what is happening during the build. > > Should performance be too much of a problem having a bind mount of > the build directory on top of the overlay should give normal > performance to everything that is obeying good practice. > > After the build completes the directory that was mounted as upper > could be scanned to find any wayward writes that had occurred... > > This would not require LD_PRELOAD or ptrace eliminating most of the > "high magic" currently used. > > Just yesterday I had a lot of ptrace failures while trying something > odd with ROOT= and custom USE > > Jim McMechan I kinda like this idea, It looks to me to have pretty much all the benefits of a sandbox and nearly none of the drawbacks. Sounds like it should get more research into this idea, figure out it's limitations and if there are any caveats. -- Brian Dolbec