Bug#619048: [buildd-tools-devel] Bug#619048: Permission problems when build fails, ~/.sbuildrc ignored
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
Bug#619048: [buildd-tools-devel] Bug#619048: Permission problems when build fails, ~/.sbuildrc ignored
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. signature.asc Description: Digital signature
