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 DDCC31396D0 for ; Fri, 22 Sep 2017 12:27:51 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 32F2D1FC16E; Fri, 22 Sep 2017 12:27:46 +0000 (UTC) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (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 DE82F1FC16A for ; Fri, 22 Sep 2017 12:27:45 +0000 (UTC) Received: by mail-io0-x22d.google.com with SMTP id 21so2651341iof.6 for ; Fri, 22 Sep 2017 05:27:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=jicDp5S8wh4SpHNnjhYYiuulJat2c9FyBPeAfG7yY5Q=; b=rF+hnrc9P3hn/VCFQBQ0YR2ihXUrJZzXGPVIx2IbfjLjO7TF0sR1NADHOFFGewipqt cEF9nkkimmECQEOw6fsLlzCw5CdBelarRDprzaWrHeRTEpYQacSPnNz1LDHo1iVSGwqS +YWFKDTCrH+E3Mm5g9lhGo6iYUg5jEMzyCmBgCMDNWG7dchSVOuMLOZzNkaoHVMgU9Tu LrGZDBzTqDvG+lklbwNk2G1kdgRKMWakbHEnAbHMB5UsX3RyxpwLvHMq5A8ar35l8MuZ 4U06kRgvhJyUQ0VGpJpBNVXnIWxqM3TejX6nlljKrq/tsx7kHalMa39FxqmihufwBA6S XfxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=jicDp5S8wh4SpHNnjhYYiuulJat2c9FyBPeAfG7yY5Q=; b=ntXcGrq7/7TjmWokO1r1EEZ31JirOOXTrCWG0kSoPr76T2IKoe5fLP9L2Djk94zdjY 8msafmhY0bJpt1avyF/T+qEJQaB+57qZgWL9QxCipglSG779prvcE4+DNPjqQlMLoA7I 0h+VenLyGS787vryZO4yyNopWheanbKendF8JEDiyimquYPfUu/hOMNp+3XoG6gZ7yxs vbHFw+VEWtTcFegBHL453Nu+MHZLJ9AizXGprxPNOkSko/9/2l6kRK5RCZrk3uBhfqpV Yn4lab1nc3kMDUxbhZPNJ4/yY5xpo2M2MDqekDkczm3kbK/7U8LLspOw0Z4ucg39mPZq 9rew== X-Gm-Message-State: AHPjjUi+65Cx1qzG7WXKcy+x5LM8X42DzqsATKtnGEANTsWa7ijxP+bd DD0BmTpARAu6e1/1mUI2Asq2+4z7ZLNWKUkvJMD0yWw0 X-Google-Smtp-Source: AOwi7QCMYu0PZc35kVNHq/ltoAIPfjtlEqY6BoidVgynZoij4KuOO0XxBhpYqTAHXRJq9BB89tYrpG6k3AdSGCAVsb0= X-Received: by 10.107.162.203 with SMTP id l194mr8313891ioe.50.1506083264380; Fri, 22 Sep 2017 05:27:44 -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 Sender: freemanrich@gmail.com Received: by 10.107.30.84 with HTTP; Fri, 22 Sep 2017 05:27:43 -0700 (PDT) In-Reply-To: <20170922123854.179f605c@sf> 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> From: Rich Freeman Date: Fri, 22 Sep 2017 08:27:43 -0400 X-Google-Sender-Auth: AoBZEeGa1K-5_J-O7ssNh1YBguc Message-ID: Subject: Re: [gentoo-dev] Reviving the Sandbox project To: gentoo-dev Content-Type: text/plain; charset="UTF-8" X-Archives-Salt: 7a8ff38c-1f23-40dd-a737-790334e1023a X-Archives-Hash: 7c4b92652306ad617e2f0989e8c42727 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