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

Tue Mar 22 22:29:25 UTC 2011

tags 619048 pending
thanks

Hello,

On pirmadienis 21 Kovas 2011 00:14:02 Roger Leigh wrote:
> 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.

$ ls -l /mnt/buildd/build-trees/
viso 0
drwxr-x--- 1 sbuild sbuild 282 2011-03-20 19:03 qtscriptgenerator-EslCpI
drwxr-x--- 1 sbuild sbuild 450 2011-03-20 19:56 qtscriptgenerator-GsSs02
drwxr-x--- 1 sbuild sbuild 450 2011-03-20 19:48 qtscriptgenerator-L0mTJF
drwxr-x--- 1 sbuild sbuild 450 2011-03-20 19:32 qtscriptgenerator-oZEJge
drwxr-x--- 1 sbuild sbuild 450 2011-03-20 19:58 qtscriptgenerator-qXbyHY
drwxr-x--- 1 sbuild sbuild 282 2011-03-20 18:59 qtscriptgenerator-WzulBo
$

> 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)

$ /usr/lib/sbuild/sbuild-schroot -c unstable-amd64-sbuild -- id
uid=114(sbuild) gid=117(sbuild) groups=117(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.

They are.

> 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?

It is present.

> > 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.

It had effect. So ~/.sbuildrc is being read.

> 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.

I would like this (the user which is used inside sbuild) to be configurable if 
possible. Then I would set this option to $ENV{USER} in ~/.sbuildrc. There 
seems to be some support for this via $self->get_conf('BUILD_USER'), isn't 
there?

> 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).

Well ok, it's obviously a noble effort as long as it pays off by DSA putting 
sbuild on porter machines and eliminating the need to ask for build-depends 
each time you want to build something there.

> > 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.

The problem with sbuild-shell is that it does not play well with my workflow.
What's more it is pretty limited as it does not accept many schroot options 
including -u or is not capable to run a custom command directly in place of 
the shell. Luckily, in case of cloned schroots, I can copy&paste session id 
and run schroot directly (copy&pasting is another annoyance but that's a topic 
for a new wishlist).

As you see I keep all build trees in /mnt/buildd/build-trees/. Whenever the 
build failed, I used to edit the affected build tree "from outside" and 
rebuild manually with the help of sbuild-shell/schroot (to test if changes 
work).

The reason for outside editing is that chroot has no devel tools which I 
typically use. And I don't want to install them in the chroot in order to keep 
it minimal (or otherwise if you want to do it post-failure it requires to run 
apt-get each time). So clearly as /mnt/buildd/build-trees/* are owned by 
sbuild user now, I can no longer edit those files directly with my user.

> > 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.

It seems that you fixed permission part of this bug in 
9607fdaacebe9c4008efbeaaaa7defa5ec36ce56. I would still like to get BUILD_USER 
configurable (see above) but I can open another bug about this if it has any 
prospects. Please let me know. Otherwise, feel free to close this bug with the 
upload of 0.62.1 to Debian archive.

-- 
Modestas Vainius <modax at debian.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20110323/a765ff65/attachment.pgp>