From: Colin Walters <walters@verbum.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: John Stoffel <john@stoffel.org>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: chroot(2) and bind mounts as non-root
Date: Thu, 08 Dec 2011 12:15:17 -0500 [thread overview]
Message-ID: <1323364518.10724.65.camel@lenny> (raw)
In-Reply-To: <201112081704.22453.arnd@arndb.de>
On Thu, 2011-12-08 at 17:04 +0000, Arnd Bergmann wrote:
> I think the better question to ask is what is missing from 'schroot', which
> is commonly used for exactly this purpose. Is it just about avoing the
> suid bit for /usr/bin/schroot or something else?
The trust model for schroot is that it only allows executing code
downloaded from URLs in /etc/schroot/schroot.conf. That means it
requires root for the initial setup to edit that config file, which
disqualifies it from my use case (no part of the compilation should
require root).
In my approach, you can keep the OS tree (/usr/include, /usr/bin/gcc)
owned by the user - there is absolutely no root-owned process running
under any indirect control of the user (except the tiny bit for my new
setuid binary).
Now ultimately to *run* your installed program locally (say you're
hacking on a system daemon like gdm), then clearly you need root. But
nothing before that should. And if you're not running it locally (e.g.
you're cross compiling, running a build server which distributes
binaries to other machines), then there is no root required.
next prev parent reply other threads:[~2011-12-08 17:15 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-07 17:54 chroot(2) and bind mounts as non-root Colin Walters
2011-12-07 19:36 ` John Stoffel
2011-12-08 16:10 ` Colin Walters
2011-12-08 18:14 ` John Stoffel
2011-12-08 18:26 ` Colin Walters
2011-12-09 0:49 ` Sven-Haegar Koch
2011-12-09 14:55 ` John Stoffel
2011-12-09 15:06 ` Colin Walters
2011-12-08 17:04 ` Arnd Bergmann
2011-12-08 17:15 ` Colin Walters [this message]
2011-12-07 19:40 ` Andy Lutomirski
2011-12-08 16:58 ` Colin Walters
2011-12-07 20:34 ` H. Peter Anvin
2011-12-07 20:54 ` Alan Cox
2011-12-15 18:55 ` Andrew G. Morgan
2011-12-16 15:44 ` Colin Walters
2011-12-18 1:22 ` Andrew G. Morgan
2011-12-18 15:19 ` Colin Walters
2011-12-10 5:29 ` Serge E. Hallyn
2011-12-12 16:41 ` Colin Walters
2011-12-12 23:11 ` Serge E. Hallyn
2011-12-15 20:56 ` Colin Walters
2011-12-16 6:14 ` Eric W. Biederman
2011-12-18 16:01 ` Colin Walters
2011-12-19 0:55 ` Eric W. Biederman
2011-12-19 4:06 ` Serge E. Hallyn
2011-12-19 9:22 ` Eric W. Biederman
2011-12-20 16:49 ` Colin Walters
2011-12-20 21:23 ` Colin Walters
2011-12-21 18:15 ` Steve Grubb
2012-01-03 23:13 ` Eric W. Biederman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1323364518.10724.65.camel@lenny \
--to=walters@verbum.org \
--cc=arnd@arndb.de \
--cc=john@stoffel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox