sbuild and its tools are hardly usable on chroots where the current
user is not allowed to be root (e.g. via root-groups). For example,
sbuild-update requires  you to enter your password 14 times just to
perform one apt-get update.

$ sbuild-update -u sid-i386
[schroot] password for root:
[schroot] password for root:
[schroot] password for root:
[schroot] password for root:
[schroot] password for root:
[schroot] password for root:
[schroot] password for root:
[schroot] password for root:
[schroot] password for root:
[schroot] password for root:
[schroot] password for root:
sid-i386: Performing update.
[schroot] password for root:
Get:1 http://localhost sid InRelease [234 kB]
Get:2 http://localhost sid/main i386 Packages [6097 kB]
Get:3 http://localhost sid/main Translation-en [4007 kB]
Fetched 10.3 MB in 7s (1322 kB/s)
Reading package lists... Done
[schroot] password for root:
[schroot] password for root:

chroot requiring root access, we ask the user for their password.
Unlike sudo, we don't currently provide any caching of the
credentials for the current tty.

The current intention is that if you want to use sbuild, you need
to be in root-groups.  All the chroot setup, including package
installation and removal, all need root.  It's an aspect of sbuild's
design I've never been happy with.

Do you have any suggestion about how this could be improved?

My own thoughts are:
1) Only prompt the user once, when creating the session, after which
   we retain the credentials for the session lifetime and/or a
   configurable time period (for the current tty).
   This strategy is at the schroot level, making it behave a bit
   more like sudo.
2) Don't to building using the current user; instead do it as an
   sbuild system user which has the ability to gain root in the
   chroots.  This will completely remove any requirement for the
   user running sbuild to have root privs at any level.  However, the
   additional level of indirection removes the ability for the user
   to access the chroot.

I'm happy to do both.  (1) will have to be post-wheezy for schroot.
(2) is something I've wanted for many years, but will require a setuid
wrapper for running sbuild.  This is what the (currently incomplete)
csbuild wrapper in schroot is for.  Again, this would require doing
post-wheezy since it's been frozen now.


Regards,
Roger

Yes, with added checking for the current terminal, so that the
credentials cannot be misused from programs running in another
terminal (that's how sudo does it nowadays).

I guess I do want to enter a password before building.

I think I prefer (1).

Hi,

is this feature already available in schroot?

Should this bug thus be moved to schroot?

My patch in [1] allows sbuild to run without the user outside the chroot to
have any direct access to the chroot. All communication is done through
schroot.

[1] http://lists.alioth.debian.org/pipermail/buildd-tools-devel/2015-December/010172.html

That patch in theory allows to build entirely without becoming root by using
Linux namespaces but because of that comes with its own set of problems. Some
because of the immaturity of this method and others are of conceptual nature.

Thanks!

cheers, josch