On Thu, Jan 24, 2019 at 06:06:30PM -0500, Antoine Beaupre wrote:
> Package: sbuild
> Version: 0.78.0-2
> Severity: normal
>
> 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?
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
