[buildd-tools-devel] Bug#608840: Bug#608840: Bug#608840: --chroot-setup-commands does not run as root

[Roger Leigh]

On Wed, Nov 06, 2013 at 03:08:59PM +0000, Wookey wrote:
> +++ Roger Leigh [2013-10-01 19:51 +0100]:
> > On Tue, Oct 01, 2013 at 02:14:58PM +0100, Wookey wrote:
> > > I have now been using this patch in production for a few months and it
> > > has proved effective.
> > > 
> > > As there have been no comments/objections to the implementation can
> > > this just go in the next release?
> > > 
> > > Is there a schedule for the next release? I would like to stop
> > > maintaining this as a fork as soon as possible. We've missed Ubuntu
> > > Saucy unfortunately.
> > 
> > Hi Wookey,
> > 
> > I'm sure it can go into the next release.  If you have commit access,
> > please feel free to merge it if you like.
> 
> I don't believe I have commit access. If you give it to me I'll try to do this.

If you add yourself to the "buildd-tools" alioth project, I can
add you as a team member, which will give you commit access.

> > Apologies for the delay here
> 
> > I'm just getting a couple of schroot releases (1.6.6 and 1.7.1) ready
> > now, which I've been working on for the last couple of weeks.  Should
> > be done in the next day or so.  As soon as I draw a line under that,
> > it's sbuild's turn for attention, and I'll merge all the outstanding
> > patches and tackle a bunch of the most important open bugs.  So I would
> > estimate that we should have an upload in the next week or two
> > depending on the amount of work and testing which needs doing.
> 
> Where is this bug at? I've seen a couple of sbuild releases go by, but
> not including this fix, which is a simple one so I was hoping to see it
> in.

It's the next thing on my todo list, and I can only apologise for
the delay.  Time for Debian stuff has been sorely lacking the last
month or so.  If you're happy to rebase/merge your work onto the
current git master and push it once you have access, you are welcome
to do so.

> I've just come across another use-case, where I am using a qemu-based
> chroot to 'debianise' an ubuntu chroot as a new-arch buildd bootstrap
> process. That needs a script run as root inside the chroot before the
> update to sync the tarball image up to dpkg -i the set of
> already-debianised packages. (apt prefs and a repo wouldn't work as some
> extra hackery is required due to distro differences (e.g flex is two
> packages in Ubuntu, but one in debian curreently).
> 
> OK this is a bit obscure, but it's just another example of 'I need to run
> a script as root inside the chroot once it is set up'.

This is definitely useful to be able to support.  In general, I do
worry a bit about adding such interfaces since they do allow the
invoking user to run arbitrary stuff as root in the chroot,
something which we've spent some years trying to isolate to limit
the scope of what a normal user can do.  But in the common case
this is all being done on the user's own machine.  However, I
would like, longer-term, to be able to securely isolate the
build environment completely from the user; this is certainly
something an improved permissions model could cater for though.


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