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