Debian Bug report logs - #637870
Provide more isolation than just chroot

Reply or subscribe to this bug.

Display info messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Vincent Bernat <bernat@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: Provide more isolation than just chroot

Date: Mon, 15 Aug 2011 12:46:31 +0200

Package: schroot
Version: 1.4.23-1
Severity: wishlist

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi!

Recent Linux kernels allow more advanced isolation than just
chrooting. From clone(2) manpage, those possibilities exist:

 - CLONE_NEWPID: new PID namespace, including the fact that when the
   initial process dies (in case of schroot, this could be the shell),
   all other processes start die as well. This would be a very cool
   feature when starting daemons in the chroot.
 - CLONE_NEWNS: mentioned in bug #488225.
 - CLONE_NEWIPC: new IPC namespace, with complete destruction on exit
 - CLONE_NEWNET: new network namespace, maybe could be done later
   since it needs to be configured properly to be useful.
 - CLONE_NEWUTS: not sure when it is useful

CLONE_NEWPID + CLONE_NEWNS + CLONE_NEWIPC would be great!

I am unsure if this can be done into setup scripts but I will look at
it. Maybe with an helper?

- -- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages schroot depends on:
ii  libboost-filesystem1.46.1   1.46.1-6     filesystem operations (portable pa
ii  libboost-program-options1.4 1.46.1-6     program options library for C++
ii  libboost-regex1.46.1        1.46.1-6     regular expression library for C++
ii  libboost-system1.46.1       1.46.1-6     Operating system (e.g. diagnostics
ii  libc6                       2.13-16      Embedded GNU C Library: Shared lib
ii  libgcc1                     1:4.6.1-6    GCC support library
ii  liblockdev1                 1.0.3-1.4+b1 Run-time shared library for lockin
ii  libpam0g                    1.1.3-2      Pluggable Authentication Modules l
ii  libstdc++6                  4.6.1-6      GNU Standard C++ Library v3
ii  libuuid1                    2.19.1-5     Universally Unique ID library
ii  schroot-common              1.4.23-1     common files for schroot

schroot recommends no packages.

Versions of packages schroot suggests:
pn  aufs-modules | unionfs-modul <none>      (no description available)
pn  btrfs-tools                  <none>      (no description available)
ii  debootstrap                  1.0.35      Bootstrap a basic Debian system
ii  lvm2                         2.02.84-3.1 The Linux Logical Volume Manager
ii  unzip                        6.0-5       De-archiver for .zip files

- -- Configuration Files:
/etc/schroot/schroot.conf changed [not included]

- -- no debconf information

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk5I+QQACgkQKFvXofIqeU6JTwCgoGSWB/vUDK3iAId0O43U01og
kC8AmwYTW6h1x4upNMxXpdvZtb4YkMgl
=7PRW
-----END PGP SIGNATURE-----

Message #10 received at 637870@bugs.debian.org (full text, mbox, reply):

From: Roger Leigh <rleigh@codelibre.net>

To: Vincent Bernat <bernat@debian.org>, 637870@bugs.debian.org

Subject: Re: [buildd-tools-devel] Bug#637870: Provide more isolation than just chroot

Date: Mon, 15 Aug 2011 14:18:00 +0100

[Message part 1 (text/plain, inline)]

On Mon, Aug 15, 2011 at 12:46:31PM +0200, Vincent Bernat wrote:
> Recent Linux kernels allow more advanced isolation than just
> chrooting. From clone(2) manpage, those possibilities exist:
> 
>  - CLONE_NEWPID: new PID namespace, including the fact that when the
>    initial process dies (in case of schroot, this could be the shell),
>    all other processes start die as well. This would be a very cool
>    feature when starting daemons in the chroot.
>  - CLONE_NEWNS: mentioned in bug #488225.
>  - CLONE_NEWIPC: new IPC namespace, with complete destruction on exit
>  - CLONE_NEWNET: new network namespace, maybe could be done later
>    since it needs to be configured properly to be useful.
>  - CLONE_NEWUTS: not sure when it is useful
> 
> CLONE_NEWPID + CLONE_NEWNS + CLONE_NEWIPC would be great!
> 
> I am unsure if this can be done into setup scripts but I will look at
> it. Maybe with an helper?

This has been something we have wanted to do for some time--at least
for CLONE_NEWPID and CLONE_NEWNS.

The main problem preventing its use is the current architecture of
schroot, particularly when using sessions.  When a session is created,
it's created by one schroot invocation, used in a separate invocation
and then deleted in yet another.  This means that we can't use
CLONE_NEWNS since we want to use the namespace created in an
unrelated process.  To do that we need a persistent process to
"own" the namespace to which we can then attach to to run commands--
but this needs having a client-server protocol AFAICT, though I may
be overcomplicating things.

We currently run programs with a fork()/chroot()/exec() sequence.
I have started work on modularising the session code in
sbuild/sbuild-session.cc which would make this logic pluggable, and
allow the use of linux-specific logic on Linux, and the standard
method otherwise (and would also provide a means to use kvm/cgroups/
lxc/vservers etc. via custom modules).  This would permit CLONE_NEWPID
to be used, but AFAICT we still need a daemon-like setup to use
CLONE_NEWNS.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.

[signature.asc (application/pgp-signature, inline)]

Message #15 received at 637870@bugs.debian.org (full text, mbox, reply):

From: Vincent Bernat <bernat@debian.org>

To: Roger Leigh <rleigh@codelibre.net>

Cc: 637870@bugs.debian.org

Subject: Re: [buildd-tools-devel] Bug#637870: Provide more isolation than just chroot

Date: Mon, 15 Aug 2011 16:49:05 +0200

[Message part 1 (text/plain, inline)]

OoO  En ce début  d'après-midi ensoleillé  du lundi  15 août  2011, vers
15:18, Roger Leigh <rleigh@codelibre.net> disait :

> The main problem preventing its use is the current architecture of
> schroot, particularly when using sessions.  When a session is created,
> it's created by one schroot invocation, used in a separate invocation
> and then deleted in yet another.  This means that we can't use
> CLONE_NEWNS since we want to use the namespace created in an
> unrelated process.  To do that we need a persistent process to
> "own" the namespace to which we can then attach to to run commands--
> but this needs having a client-server protocol AFAICT, though I may
> be overcomplicating things.

It  seems that  with  recent kernel,  it  is possible  to  attach to  an
existing namespace using setns() syscall:
 http://lxc.git.sourceforge.net/git/gitweb.cgi?p=lxc/lxc;a=blob;f=src/lxc/namespace.c;h=aca29d4f87aa37c4133fe98f38c1b3296b153e66;hb=HEAD#l85

Therefore, you still need a  persistent process to own the namespace but
you just need to keep its PID and use it to attach to its namespaces.
-- 
Vincent Bernat ☯ http://vincent.bernat.im

Use self-identifying input.  Allow defaults.  Echo both on output.
            - The Elements of Programming Style (Kernighan & Plauger)

[Message part 2 (application/pgp-signature, inline)]

Message #20 received at 637870@bugs.debian.org (full text, mbox, reply):

From: Vincent Bernat <bernat@debian.org>

To: Roger Leigh <rleigh@codelibre.net>

Cc: 637870@bugs.debian.org

Subject: Re: [buildd-tools-devel] Bug#637870: Provide more isolation than just chroot

Date: Mon, 15 Aug 2011 16:51:48 +0200

[Message part 1 (text/plain, inline)]

OoO Vers  la fin de l'après-midi du  lundi 15 août 2011,  vers 16:49, je
disais:

>> The main problem preventing its use is the current architecture of
>> schroot, particularly when using sessions.  When a session is created,
>> it's created by one schroot invocation, used in a separate invocation
>> and then deleted in yet another.  This means that we can't use
>> CLONE_NEWNS since we want to use the namespace created in an
>> unrelated process.  To do that we need a persistent process to
>> "own" the namespace to which we can then attach to to run commands--
>> but this needs having a client-server protocol AFAICT, though I may
>> be overcomplicating things.

> It  seems that  with  recent kernel,  it  is possible  to  attach to  an
> existing namespace using setns() syscall:
>  http://lxc.git.sourceforge.net/git/gitweb.cgi?p=lxc/lxc;a=blob;f=src/lxc/namespace.c;h=aca29d4f87aa37c4133fe98f38c1b3296b153e66;hb=HEAD#l85

> Therefore, you still need a  persistent process to own the namespace but
> you just need to keep its PID and use it to attach to its namespaces.

It seems that keeping a process is not necessary:
 http://lwn.net/Articles/407495/

I don't know if all this is available in mainline kernel.
-- 
Vincent Bernat ☯ http://vincent.bernat.im

printk("??? No FDIV bug? Lucky you...\n");
	2.2.16 /usr/src/linux/include/asm-i386/bugs.h

[Message part 2 (application/pgp-signature, inline)]

Message #25 received at 637870@bugs.debian.org (full text, mbox, reply):

From: Roger Leigh <rleigh@codelibre.net>

To: Vincent Bernat <bernat@debian.org>, 637870@bugs.debian.org

Subject: Re: [buildd-tools-devel] Bug#637870: Bug#637870: Provide more isolation than just chroot

Date: Mon, 15 Aug 2011 16:23:30 +0100

[Message part 1 (text/plain, inline)]

On Mon, Aug 15, 2011 at 04:51:48PM +0200, Vincent Bernat wrote:
> OoO Vers  la fin de l'après-midi du  lundi 15 août 2011,  vers 16:49, je
> disais:
> 
> >> The main problem preventing its use is the current architecture of
> >> schroot, particularly when using sessions.  When a session is created,
> >> it's created by one schroot invocation, used in a separate invocation
> >> and then deleted in yet another.  This means that we can't use
> >> CLONE_NEWNS since we want to use the namespace created in an
> >> unrelated process.  To do that we need a persistent process to
> >> "own" the namespace to which we can then attach to to run commands--
> >> but this needs having a client-server protocol AFAICT, though I may
> >> be overcomplicating things.
> 
> > It  seems that  with  recent kernel,  it  is possible  to  attach to  an
> > existing namespace using setns() syscall:
> >  http://lxc.git.sourceforge.net/git/gitweb.cgi?p=lxc/lxc;a=blob;f=src/lxc/namespace.c;h=aca29d4f87aa37c4133fe98f38c1b3296b153e66;hb=HEAD#l85
> 
> > Therefore, you still need a  persistent process to own the namespace but
> > you just need to keep its PID and use it to attach to its namespaces.
> 
> It seems that keeping a process is not necessary:
>  http://lwn.net/Articles/407495/
> 
> I don't know if all this is available in mainline kernel.

Very useful information, thanks.  If we create the namespace before
running the setup scripts, then one of the setup scripts can bind
mount its namespace under e.g. /var/lib/schroot/ns
so we can access it later on with setns().

I think setns is in the mainline kernel.  The issue is in the glibc
wrappers:

/usr/include/asm-generic/unistd.h:#define __NR_setns 268
/usr/include/asm-generic/unistd.h:__SYSCALL(__NR_setns, sys_setns)
/usr/include/asm/unistd_64.h:#define __NR_setns				308
/usr/include/asm/unistd_64.h:__SYSCALL(__NR_setns, sys_setns)
/usr/include/asm/unistd_32.h:#define __NR_setns		346

So it looks like the raw system call is there, but there's no actual
"setns(2)" function prototyped for us to use.  We could use syscall(2)
directly, but I would prefer to wait until it's properly supported.
It might well be in the next glibc version though, at which point we
can look at doing this.

% ls /proc/self/ns
ipc  net  uts

There's no "mnt" namespace here, which might be an issue.  This is with
Linux 3.0.0.  Maybe it's not supported in /proc yet?


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.

[signature.asc (application/pgp-signature, inline)]

Message #30 received at 637870@bugs.debian.org (full text, mbox, reply):

From: Vincent Bernat <bernat@debian.org>

To: Roger Leigh <rleigh@codelibre.net>

Cc: 637870@bugs.debian.org

Subject: Re: [buildd-tools-devel] Bug#637870: Bug#637870: Provide more isolation than just chroot

Date: Mon, 15 Aug 2011 18:00:00 +0200

[Message part 1 (text/plain, inline)]

OoO Lors de la soirée naissante du lundi 15 août 2011, vers 17:23, Roger
Leigh <rleigh@codelibre.net> disait :

> % ls /proc/self/ns
> ipc  net  uts

> There's no "mnt" namespace here, which might be an issue.  This is with
> Linux 3.0.0.  Maybe it's not supported in /proc yet?

Yes, no mnt, no pid. It does not seem to be implemented in 3.0.1:
 http://lxr.linux.no/linux+v3.0.1/include/linux/proc_fs.h#L244

Patches seem to be available here (some of them are merged mainline):
 http://lxc.sourceforge.net/patches/linux/

There is no update since 2.6.38. And I don't find any patch update since
March 2011 on the web.
-- 
Vincent Bernat ☯ http://vincent.bernat.im

panic("Foooooooood fight!");
	2.2.16 /usr/src/linux/drivers/scsi/aha1542.c

[Message part 2 (application/pgp-signature, inline)]

Message #35 received at 637870@bugs.debian.org (full text, mbox, reply):

From: Roger Leigh <rleigh@codelibre.net>

To: Vincent Bernat <bernat@debian.org>, 637870@bugs.debian.org

Subject: Re: [buildd-tools-devel] Bug#637870: Bug#637870: Bug#637870: Provide more isolation than just chroot

Date: Mon, 15 Aug 2011 17:13:38 +0100

[Message part 1 (text/plain, inline)]

On Mon, Aug 15, 2011 at 06:00:00PM +0200, Vincent Bernat wrote:
> OoO Lors de la soirée naissante du lundi 15 août 2011, vers 17:23, Roger
> Leigh <rleigh@codelibre.net> disait :
> 
> > % ls /proc/self/ns
> > ipc  net  uts
> 
> > There's no "mnt" namespace here, which might be an issue.  This is with
> > Linux 3.0.0.  Maybe it's not supported in /proc yet?
> 
> Yes, no mnt, no pid. It does not seem to be implemented in 3.0.1:
>  http://lxr.linux.no/linux+v3.0.1/include/linux/proc_fs.h#L244
> 
> Patches seem to be available here (some of them are merged mainline):
>  http://lxc.sourceforge.net/patches/linux/
> 
> There is no update since 2.6.38. And I don't find any patch update since
> March 2011 on the web.

OK, so it's still essentially a "work in progress" in the kernel.
Looks like we'll have to wait a few months before we can implement this
in schroot, but I'm happy to do so once it's ready!


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.

[signature.asc (application/pgp-signature, inline)]

Message #40 received at 637870@bugs.debian.org (full text, mbox, reply):

From: Roger Leigh <rleigh@codelibre.net>

To: Vincent Bernat <bernat@debian.org>, 637870@bugs.debian.org

Subject: Re: Bug#637870: Provide more isolation than just chroot

Date: Sat, 3 Nov 2012 14:03:33 +0000

On Mon, Aug 15, 2011 at 12:46:31PM +0200, Vincent Bernat wrote:
> Recent Linux kernels allow more advanced isolation than just
> chrooting. From clone(2) manpage, those possibilities exist:
> 
>  - CLONE_NEWPID: new PID namespace, including the fact that when the
>    initial process dies (in case of schroot, this could be the shell),
>    all other processes start die as well. This would be a very cool
>    feature when starting daemons in the chroot.
>  - CLONE_NEWNS: mentioned in bug #488225.
>  - CLONE_NEWIPC: new IPC namespace, with complete destruction on exit
>  - CLONE_NEWNET: new network namespace, maybe could be done later
>    since it needs to be configured properly to be useful.
>  - CLONE_NEWUTS: not sure when it is useful
> 
> CLONE_NEWPID + CLONE_NEWNS + CLONE_NEWIPC would be great!
> 
> I am unsure if this can be done into setup scripts but I will look at
> it. Maybe with an helper?

On the master branch (1.7.0 development), I've now implemented
initial unshare(2) support.  Currently limited to CLONE_NEWNET,
but others can be added easily now the groundwork is done.

At the moment, as discussed in this report already, the way schroot
handles sessions makes is impractical to support NEWPID and NEWNS.
But I plan longer-term to make this possible, but this requires
fairly significant refactoring.  We'd need to make a schroot
session a persistent process you connect to, probably over a
local socket, so that the pid and filesystem namespaces can
persist.  This would actually be beneficial for a number of other
reasons, but it's going to be a lot of work, so won't be done
immediately.

Others that can be implemented immediately:
NEWIPC
CLONE_SYSVSEM
CLONE_NEWUTS

Because these all take effect at exec time, they would isolate
each command started in the chroot, rather than the chroot as
a whole--that will have to wait until we have socket-based
persistence.  But still useful for e.g. buildds since they
prevent leaking of resources and complete networking
restriction just for the build step.


With the current implementation, I've make it work with the
  -o unshare.newnet=true
user option on the command-line.  You can also set it when
creating a session, and it should affect all commands run
in that session.

I'm not sure if this is the best possible interface though--
do we want to tie the options directly to the linux unshare()
interface?  I'm not sure yet.  Depends on how linux-specific
this facility is to be.  Currently linux-only.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux    http://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-    GPG Public Key      F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800

Message #45 received at 637870@bugs.debian.org (full text, mbox, reply):

From: Roger Leigh <rleigh@codelibre.net>

To: Vincent Bernat <bernat@debian.org>, 637870@bugs.debian.org

Subject: Re: [buildd-tools-devel] Bug#637870: Provide more isolation than just chroot

Date: Sun, 4 Nov 2012 01:35:27 +0000

On Sat, Nov 03, 2012 at 02:03:33PM +0000, Roger Leigh wrote:
> On Mon, Aug 15, 2011 at 12:46:31PM +0200, Vincent Bernat wrote:
> > Recent Linux kernels allow more advanced isolation than just
> > chrooting. From clone(2) manpage, those possibilities exist:
> > 
> >  - CLONE_NEWPID: new PID namespace, including the fact that when the
> >    initial process dies (in case of schroot, this could be the shell),
> >    all other processes start die as well. This would be a very cool
> >    feature when starting daemons in the chroot.
> >  - CLONE_NEWNS: mentioned in bug #488225.
> >  - CLONE_NEWIPC: new IPC namespace, with complete destruction on exit
> >  - CLONE_NEWNET: new network namespace, maybe could be done later
> >    since it needs to be configured properly to be useful.
> >  - CLONE_NEWUTS: not sure when it is useful
> > 
> > CLONE_NEWPID + CLONE_NEWNS + CLONE_NEWIPC would be great!
> > 
> > I am unsure if this can be done into setup scripts but I will look at
> > it. Maybe with an helper?
> 
> On the master branch (1.7.0 development), I've now implemented
> initial unshare(2) support.  Currently limited to CLONE_NEWNET,
> but others can be added easily now the groundwork is done.
> 
> At the moment, as discussed in this report already, the way schroot
> handles sessions makes is impractical to support NEWPID and NEWNS.
> But I plan longer-term to make this possible, but this requires
> fairly significant refactoring.  We'd need to make a schroot
> session a persistent process you connect to, probably over a
> local socket, so that the pid and filesystem namespaces can
> persist.  This would actually be beneficial for a number of other
> reasons, but it's going to be a lot of work, so won't be done
> immediately.
> 
> Others that can be implemented immediately:
> NEWIPC
> CLONE_SYSVSEM
> CLONE_NEWUTS

These three are now also done.  Definable keys:

unshare.net
unshare.sysvipc
unshare.sysvsem
unshare.uts


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux    http://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-    GPG Public Key      F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800

Message #50 received at 637870-close@bugs.debian.org (full text, mbox, reply):

From: Roger Leigh <rleigh@debian.org>

To: 637870-close@bugs.debian.org

Subject: Bug#637870: fixed in schroot 1.7.0-1

Date: Sun, 05 May 2013 15:00:07 +0000

Source: schroot
Source-Version: 1.7.0-1

We believe that the bug you reported is fixed in the latest version of
schroot, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 637870@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Roger Leigh <rleigh@debian.org> (supplier of updated schroot package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Format: 1.8
Date: Sun, 05 May 2013 11:33:16 +0100
Source: schroot
Binary: schroot-common libsbuild-1.7.0 libsbuild-dev libsbuild-1.7.0-dbg libsbuild-doc schroot dchroot dchroot-dsa
Architecture: source all amd64
Version: 1.7.0-1
Distribution: experimental
Urgency: low
Maintainer: Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>
Changed-By: Roger Leigh <rleigh@debian.org>
Description: 
 dchroot    - Execute commands in a chroot environment
 dchroot-dsa - Execute commands in a chroot environment
 libsbuild-1.7.0 - shared library for the Debian source builder
 libsbuild-1.7.0-dbg - Debugging symbols for the Debian source builder
 libsbuild-dev - development files for the Debian source builder
 libsbuild-doc - development documentation for the Debian source builder
 schroot    - Execute commands in a chroot environment
 schroot-common - common files for schroot
Closes: 637870
Changes: 
 schroot (1.7.0-1) experimental; urgency=low
 .
   * New upstream development release.
   * schroot:
     - Support for unsharing network devices has been added
       (Closes: #637870).  On linux, run schroot with
       "-o unshare.newnet=true", and in the chroot, all networking
       will be isolated from the host.  By default, only a localhost
       link is provided.
     - Support for "exec" scripts, removed in 1.4 and 1.6, has
       been re-added to support unsharing network devices.  These
       are regular setup scripts, called with an exec-start or
       exec-start argument.
   * libsbuild-1.7.0:
     - New package
     - Introduce a shared library.
   * libsbuild-1.7.0-dev:
     - New package.
     - Shared library debugging symbols.
   * libsbuild-dev:
     - Remove static library, and include shared library symlink.
   * debian/copyright: Update to use DEP-5 copyright format v1.0.
   * debian/control: Remove liblockdev and libuuid from Build-Depends.
   * debian/rules:
     - Build using g++ in C++11 mode.
     - Remove UUID support.
     - Support parallel= in DEB_BUILD_OPTIONS.
Checksums-Sha1: 
 1ad57061be31fcefb18370b31bcda4721f075efe 2449 schroot_1.7.0-1.dsc
 0eee39b42e1f307ac1f86b6ebf26bb50ae8f39fd 735796 schroot_1.7.0.orig.tar.xz
 c4525451ac7b1c37e19c52f1cfccdc81aea5697c 30579 schroot_1.7.0-1.debian.tar.gz
 8c98f9b1ecd0af45b1ce64a58f0800d55d4b1f91 257880 schroot-common_1.7.0-1_all.deb
 e3edd28ff2b050ecaf20426548a5eedb92c8ce5c 633682 libsbuild-1.7.0_1.7.0-1_amd64.deb
 4f1bb5a87f82f2d2d0952466ada2c7fcfb67d367 248830 libsbuild-dev_1.7.0-1_amd64.deb
 7e2d2b1df7fca0cdd3e2c31ca07e74db77ae3a8b 13820468 libsbuild-1.7.0-dbg_1.7.0-1_amd64.deb
 a61937f94db9839a84bea0e795cf50fcdbb2a653 8775234 libsbuild-doc_1.7.0-1_all.deb
 a5382ca339982cb66561ca713e0e13efe5c2f31c 484386 schroot_1.7.0-1_amd64.deb
 6a1534031ea2ff8cce9c15678744ee60399e7988 104592 dchroot_1.7.0-1_amd64.deb
 fc3ef413e6aa4902d0201ac9dd569a2f1feff085 104938 dchroot-dsa_1.7.0-1_amd64.deb
Checksums-Sha256: 
 13b3d9a64c6b85fdf5c0b17cae9d6a3d4b89b93f43e5483da30b6420caef7bdc 2449 schroot_1.7.0-1.dsc
 1fc3c5eb448bd2a8d2aeffede36316505874d11a7b16d2198d6c37d3be36df0d 735796 schroot_1.7.0.orig.tar.xz
 9202a1dea99632f5110c66dc14a7925a8478fa1ad7b8935482153063b29a1798 30579 schroot_1.7.0-1.debian.tar.gz
 210967b357631556277d025eda058966e1b92e1b50749509470005021fa362e9 257880 schroot-common_1.7.0-1_all.deb
 55030366661c7a4d370ab8a5b258a0598e2521a48525c66bcf8936acee15266c 633682 libsbuild-1.7.0_1.7.0-1_amd64.deb
 10613bafff274f651d463bedc6229738664d4bd30cd5c72842c71416dc1fd62a 248830 libsbuild-dev_1.7.0-1_amd64.deb
 e105758dfdfc5b71fc39da8bd0c72ef5f94be30ae87e3e911380edc1b184c453 13820468 libsbuild-1.7.0-dbg_1.7.0-1_amd64.deb
 1ea5d98f3ae1d3aa17319467365473b9922b4a73d0f33359351d798e46f963df 8775234 libsbuild-doc_1.7.0-1_all.deb
 b81eb467f60dcd8d0b3eeae73a851a4262f39758ffa2ad641a2a854880aae71a 484386 schroot_1.7.0-1_amd64.deb
 c391e7d73448e98f2d856c73760f8b0cb76fcbc808d66a72586907712cf560e0 104592 dchroot_1.7.0-1_amd64.deb
 03e5589b2e7f515422eb6dcc081aa7237479780a194d34d0e1966bec02323539 104938 dchroot-dsa_1.7.0-1_amd64.deb
Files: 
 cc940745537b6e1a35ded16acd81bf20 2449 admin optional schroot_1.7.0-1.dsc
 3cd7a011b89e3941b8e3dd73e2c95574 735796 admin optional schroot_1.7.0.orig.tar.xz
 561b0841923366a38f5236d475d49471 30579 admin optional schroot_1.7.0-1.debian.tar.gz
 b0dd21e0e582ea573c1c460f7ce46cb9 257880 admin optional schroot-common_1.7.0-1_all.deb
 088df6f056d8f1c01f0da09d4e13bc8b 633682 libs optional libsbuild-1.7.0_1.7.0-1_amd64.deb
 38cea202394fec4a93772079f1bd31eb 248830 libdevel optional libsbuild-dev_1.7.0-1_amd64.deb
 158c9facd107538d66a3fea4e04eda22 13820468 debug extra libsbuild-1.7.0-dbg_1.7.0-1_amd64.deb
 d3bca8f7147dc14213b72227a46994ab 8775234 doc optional libsbuild-doc_1.7.0-1_all.deb
 d5531161030e6e039e2b4024e25f139b 484386 admin optional schroot_1.7.0-1_amd64.deb
 c6ef22b5f59777d661166dedabec78d6 104592 admin optional dchroot_1.7.0-1_amd64.deb
 f12bd9789889057933cb6d0128722b19 104938 admin optional dchroot-dsa_1.7.0-1_amd64.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCgAGBQJRhjfyAAoJEOJSSsUKn1xZiGkP/2pCGYOPFrU7lHhOz5GWXGDs
NL5fNsJlPnX26WekDWOE7fgPU4pkdtFc3AZesFR+SRVtjXQTgLWJjXKzCWC6BZA1
DtjrxnWtcsy7jtWXV4TxBWW0991V36jxwlTLPKrr7ky/p3WR5vCwVfwGILbca3/S
TENzX1ZXYRDEG2REjXmOSgnvbQCiFCAza3zXW/AUllmgaGQ9pMzxs6St98t3N/8E
ID+vuhRCqk1T/l3LaKtc8lr0xQSEQ+vABeAAQg/mt5DAf3NGK0O6a9bqor3rE/+S
uOKTbBtt/yrKmVNV9b/cscIxaFpuPD+Mgrv2SCX0xVlfEPXDgURh0+Op+ANlHcnU
30f9QRB25yBRWDElwAygbn5hbc3o95trH8bJjlhpvrMoa93L/83XzyJIkz0YjnIs
4SVnxEj2BxveYSB7wDCpm2qt7R8Su3o4cQ0Yh6fNP377dihG4o5XAAHPcVHNXVJR
oyFbo2VCCYRgjI04e6lFODfd++scD+9iztFKQTqwBZavrwDrw8U2EJ6ndFv9+8dx
UWl7qBzQPVYsaBM7kShilNDM0pWIqStAOWmZKRFHhaBPiA3D5jkPMOJC9U8F+HcD
FxKF0eu/vJFZzPQURWfJno4qwIaDqR+SUi667pKSLYHrS+KODJNF4QSLZVYnn6O7
0qbDMBfbwK1YaUzjGUaI
=SLaL
-----END PGP SIGNATURE-----

Message #55 received at 637870@bugs.debian.org (full text, mbox, reply):

From: Vincent Bernat <bernat@debian.org>

To: Roger Leigh <rleigh@codelibre.net>

Cc: 637870@bugs.debian.org

Subject: Re: [buildd-tools-devel] Bug#637870: Provide more isolation than just chroot

Date: Sun, 05 May 2013 19:28:34 +0200

[Message part 1 (text/plain, inline)]

 ❦  4 novembre 2012 02:35 CET, Roger Leigh <rleigh@codelibre.net> :

> These three are now also done.  Definable keys:
>
> unshare.net
> unshare.sysvipc
> unshare.sysvsem
> unshare.uts

Hi Roger!

What about unshare.pid? Do you want me to open a separate bug about this
one or could we just reopen #637870?
-- 
Use free-form input when possible.
            - The Elements of Programming Style (Kernighan & Plauger)

[Message part 2 (application/pgp-signature, inline)]

Message #60 received at 637870@bugs.debian.org (full text, mbox, reply):

From: Roger Leigh <rleigh@codelibre.net>

To: Vincent Bernat <bernat@debian.org>

Cc: 637870@bugs.debian.org

Subject: Re: [buildd-tools-devel] Bug#637870: Provide more isolation than just chroot

Date: Sun, 5 May 2013 19:38:59 +0100

On Sun, May 05, 2013 at 07:28:34PM +0200, Vincent Bernat wrote:
>  ❦  4 novembre 2012 02:35 CET, Roger Leigh <rleigh@codelibre.net> :
> 
> > These three are now also done.  Definable keys:
> >
> > unshare.net
> > unshare.sysvipc
> > unshare.sysvsem
> > unshare.uts
> 
> Hi Roger!
> 
> What about unshare.pid? Do you want me to open a separate bug about this
> one or could we just reopen #637870?

Please do open a new bug!  I looked at supporting it, but there
was some complication which made it hard to do (at least to be
useful).  So it's definitely on the TODO list, and I'll certainly
add support when it becomes possible.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux    http://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-    GPG Public Key      F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800

Send a report that this bug log contains spam.