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 <mo...@debian.org>
signature.asc
Description: This is a digitally signed message part.
