[buildd-tools-devel] Bug#801141: Bug#801141: sbuild: Failed to lock chroot: /var/lib/sbuild/unstable-i386.tar.gz: File is not owned by user root

[Roger Leigh]

On 08/10/2015 07:13, Johannes Schauer wrote:
> Hi,
>
> Quoting PICCA Frederic-Emmanuel (2015-10-08 07:42:12)
>> Yes I did but I created a propellor property in order o maintain my sbuild
>> chroot.  Indeed this is a detail. So I end up with a tar.gz owned by
>> root:root
>
> yes, that's how it should be and is also done by sbuild-createchroot.
>
>> Then comes the upgrade whcih changed the owner into sbuild:sbuild.
>>
>> Why sbuild which is run as root do not want to lock something which is not owned by the root ?
>>
>> I do not understand  this point.
>
> The error message you saw:
>
> E: unstable-i386-sbuild-22146117-8358-467e-a857-9e8d4c79e747: Failed to lock chroot: /var/lib/sbuild/unstable-i386.tar.gz: File is not owned by user root
>
> does not come from sbuild but from schroot. So if you want to know why schroot
> needs it to be owned by the root user, you'd have to ask the schroot
> maintainer. I do not know why.
>
> The bug could nevertheless be in sbuild though because sbuild is the package
> with the postinst maintainer script that changes the ownership. I now have to
> figure out whether this chown call is actually useful or not. In the former
> case, the wiki page would have to be adapted to not recommend this location.

The file needs to be owned by root for security reasons: if it was owned 
by another user, it could be altered and then when unpacked and used 
these files are then used with full root privileges.

Regarding /var/lib/sbuild: this is owned by sbuild and used for 
maintaining its own state.  That's why we do the chown--if we don't then 
sbuild can't modify its own data.  Bottom line: the chroot tarfiles do 
not belong under this location--they are not sbuild's concern; put them 
somewhere else.  E.g. I use /srv/chroot/xxx.


Regards,
Roger