I'm trying to setup sbuild so it builds under a different user by
default. The sbuild.conf(5) manpage says:

       BUILD_USER
              STRING type.  Username used for running dpkg-buildpackage. By default the
              user  running sbuild is used within the chroot as well but that might al‐
              low a process from within the chroot to break out of the  chroot  by  at‐
              taching to a process running outside the chroot with eg. gdb and then be‐
              coming root inside the chroot through schroot and thus be able  to  leave
              the chroot.

              build_user = ...;

I'm assuming the example code there is a typo and should be really:

    $build_user = 'sbuild';

... so I add the above to my `.sbuildrc`. Then I try a build and it
fails early in the process:

E: read_command failed to execute dpkg
Use of uninitialized value $chroot_arch in scalar chomp at /usr/share/perl5/Sbui
ld/Build.pm line 3024.

The "sbuild" user exists in the chroot:

    $ schroot -c unstable-amd64-sbuild --directory / id sbuild
    uid=129(sbuild) gid=138(sbuild) groups=138(sbuild)

I have tried to look at the line pointed at by the error message:

    chomp(my $chroot_arch = $self->get('Session')->read_command(
	{ COMMAND => ['dpkg', '--print-architecture'],
	  USER => $self->get_conf('BUILD_USER'),
	  PRIORITY => 0,
	  DIR => '/' }));

.. but to figure out what the problem is, you need to dig into
`read_command`, which is quite a rabbit hole. It calls
Chroot::read_command which calls pipe_command, which calls
pipe_command_internal, which calls exec_command, and *then* we hit the
schroot specific code with get_command_internal, and *finally*
_get_exec_argv, which shows the user is passed to the `schroot -u`
argument.

When trying to reproduce the problem outside of sbuild, I therefore
do:

    $ schroot -c unstable-amd64-sbuild --directory / -u sbuild id
    [schroot] password for sbuild:

I think that's where the problem lies: stdin is probably closed which
makes the command fail. Even if it would be open, the process would
just hang asking for a password, which doesn't exist (set to '*' in
/etc/shadow).

If I run schroot as root, that works however:

    $ sudo schroot -c unstable-amd64-sbuild --directory / -u sbuild id
    uid=129(sbuild) gid=138(sbuild) groups=138(sbuild)

For what that's worth, the caller is in the `sbuild` group:

    $ grep sbuild /etc/group
    sbuild:x:138:anarcat

The schroot has that configuration:

    [unstable-amd64-sbuild]
    description=Debian unstable/amd64 autobuilder
    groups=root,sbuild
    root-groups=root,sbuild
    profile=sbuild
    type=directory
    directory=/home/chroot/unstable-amd64-sbuild
    union-type=overlay

So in *theory* it should allow users in the sbuild group to run
commands without entering a password.

Am I missing something?

The full build log is attached.

Here's the discussion Antoine and I had on IRC about this:

[22:39:57]  <anarcat>	has anyone ever made $build_user work in sbuild? here it crashes with Use of uninitialized value $chroot_arch in scalar chomp at /usr/share/perl5/Sbuild/Build.pm line 3024.
[22:53:04]  <jrtc27>	anarcat: sounds like your chroot doesn't have that user?
[22:53:37]  <jrtc27>	sorry, *host*
[22:53:43]  <jrtc27>	the user gets passed as schroot -u
[22:54:01]  <jrtc27>	that or a perms issue
[22:54:27]  <jrtc27>	or use pbuilder :P
[23:05:04]  <anarcat>	i'll file a bug :p
[23:05:13]  <anarcat>	jrtc27: sudo schroot -u sbuild works
[23:05:19]  <anarcat>	but not as a regular user
[23:18:30]  <jrtc27>	sure
[23:18:44]  <jrtc27>	but you're not running sbuild under sudo
[23:19:25]  <jrtc27>	so schroot is also run as you
[23:20:30]  <jrtc27>	$build_user follows the rules of schroot -u argument, which is documented in its manpage under AUTHENTICATION
[23:21:32]  <anarcat>	...
[23:21:38]  <anarcat>	so i need to enter the password of the sbuild user?
[23:22:05]  <anarcat>	this makes no sense to me - i can run schroot as root, but not as the sbuild user??
[23:22:31]  <jrtc27>	agreed that it doesn't make much sense if you're in root-users/groups
[23:23:08]  <anarcat>	there's also the problem that it doesn't "immediately fail with permission denied", it crashes with some unrelated, random message
[23:23:35]  <anarcat>	anyways, enough for today, thanks for the feedback!
[23:23:43]  <jrtc27>	well, yeah, the error running the command should be propagated up rather than the caller choking due to not getting output
[23:23:56]  <anarcat>	bug is #920386
[23:24:02]  <jrtc27>	so I guess two bugs, one against sbuild and one against schroot :P

Control: reassign -1 schroot

Thank you for your analysis!

I think would would be the "right" behaviour would be:

 a) schroot allows one to become a different user inside the chroot *if*
    schroot was configured that way by root in /etc/schroot/chroot.d without
    having to execute schroot under sudo (it's suid root after all)

 b) there should be a way to get schroot to throw a meaningful error message
    instead of prompting for a password. In fact it would be great if schroot
    provided a way to tell it to do exactly that: if you would ask for a
    password, then fail instead. Something like --batch or so that indicates
    that schroot cannot expect anything interactive.

Once b) is fixed, we can handle this somehow in sbuild. Thus, I'm reassigning
this bug to schroot first.

For some context about the reason for the build_user sbuild configuration
variable, read this: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661037

Thanks!

cheers, josch

Hi,

I met this problem too when trying to build under the sbuild user, since it's
rather strange that sbuild runs as my host user inside the schroot. Is there any
update? What should I do if I want to fix this? Thanks.