[buildd-tools-devel] Bug#619048: Bug#619048: Permission problems when build fails, ~/.sbuildrc ignored

[Roger Leigh]

On Sun, Mar 20, 2011 at 09:54:15PM +0200, Modestas Vainius wrote:
> sbuild fails to remove build directories whenever build fails [1]. This is probably
> because it does this as my user but not sbuild user. The regression was caused
> by the following change (probably):
> 
>       + Internally, building and other actions in the chroot are
>         performed by the 'sbuild' system user, where previously the user
>         invoking sbuild would be used instead.  The aim of this change is
>         to separate privileges to increase security and reduce the chance
>         of accidental or deliberate tampering of the build environment.
>         While the latter is not addressed by these changes, this will be
>         taken care of during future architectural changes.

I think this is the cause of the problem.  The question is why?
The logs indicate that you are using schroot.  It would be very
helpful to know what the ownership and permissions on the files
are to see why it's failing.

It would also be helpful to know if the user sbuild exists inside
the chroot:

/usr/lib/sbuild/sbuild-schroot -c unstable -- id
uid=123(sbuild) gid=131(sbuild) groups=131(sbuild)

That's what I get.  All the files with the permissions issues
should have had sbuild:sbuild ownership.

Note that if you're using schroot with clonable chroots you need
group sbuild to be present both in source-groups and
source-root-groups.

If the user sbuild isn't present inside the chroot, is the passwd file
not being synched from the main system?  Does the user sbuild exist on
the host system?

> As a side note, it should not be purging build directory in the first place
> because:
> 
> $ grep purge ~/.sbuildrc 
> $purge_build_directory="successful";
> $purge_build_deps = $purge_build_directory;
> 
> I'm not sure what's going on here (maybe it's not reading my config file
> anymore?

You can test definitively by putting a 'print "Reading .sbuildrc\n";' or
'exit(1);' in the .sbuildrc to see if it has any effect.

I'll have to check, but I don't think there has been any intentional
behaviour in the purge logic since your work for #605997.

>, worked well in the past). Personally, I don't agree with this
> "security" change and don't see any advantages it brings to the table. The
> same could have been achieved by running sbuild as sbuild user for those
> paranoid about security (whatever advantages you think it brings).

This is only the first part.  The actual advantage at this point is
minimal; it mainly identifies the parts needing to be run/owned by
the user invoking sbuild, and those needing to be run/owned by
user sbuild inside the build chroot.

The main issue with sbuild is that you effectively grant full root
access to your system to all users who run sbuild.  Before schroot, one
needed full passwordless sudo access to be able to run sbuild properly
(run apt/dpkg in the chroot, and run chroot(8)).  I wrote schroot
primarily to remove this massive security hole.  schroot only grants
root privileges inside the chroot, but even so any sbuild user has
root access inside the chroot, which pretty much translates to full
root on the host should any user wish to exercise the wish to abuse
their privileges.  The ultimate aim of the privilege separation is to
split sbuild into two parts: an unprivileged user part, and a
privileged part which will have root access to the chroots and do the
building.

While it might appear useless at first glance, 0.62.0 is the initial
steps to bringing this about.  Once complete, you won't need to do
user-specific setup such as adding users to the sbuild group, and
any user will be able to run sbuild, without granting them any
special privileges (and certainly not giving them root access).

> But if
> you view this issue from a mere DD POV, now you have to actually use sudo
> or the su to further tweak the build directory. This is inconvenient and
> pretty much redundant in my opinion.

sbuild-shell exists for this purpose.  Not sure how convenient it is
for accessing cloned chroots (you need the full session ID if you don't
want the source chroot) but it should work just fine.

> I suppose there is a growing interest in sbuild as a good replacement
> for pbuilder among developers. However, some changes really make me think
> that you forget about this group of users. Incompatible changes are made
> quite frequently and they are not well documented. Personally, I don't always
> have time to resort to reading perl code to understand why sbuild breaks...

This change should be entirely backward compatible.  The privilege
separation and addition of the sbuild user should be entirely
transparent.


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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20110320/a001d0f2/attachment.pgp>