Re: [PATCH] buildchroot: Align UID and GID of builder user with caller

[Jan Kiszka <jan.kiszka@siemens.com>]

On 12.11.18 11:06, Henning Schild wrote:
> Am Mon, 12 Nov 2018 10:52:22 +0100
> schrieb Jan Kiszka <jan.kiszka@siemens.com>:
> 
>> On 12.11.18 10:42, Henning Schild wrote:
>>> Am Mon, 12 Nov 2018 10:19:54 +0100
>>> schrieb Jan Kiszka <jan.kiszka@siemens.com>:
>>>    
>>>> On 12.11.18 10:16, [ext] Henning Schild wrote:
>>>>> I am afraid that this is not correct. The ids you are taking from
>>>>> the "host" might be taken inside the chroot. As a result creating
>>>>> the user/group would fail. Chances might be low ... This also
>>>>> assumes that
>>>>
>>>> Really? I thought that these commands are run very early during
>>>> bootstrap where there are no other users - if not, that would be a
>>>> bug.
>>>
>>> I think the only uid/gid you can really be sure about is 0. 1 could
>>> already be a regular user on the host, and 1 is "daemon" on a
>>> current debian ... probably there right after debootstrap.
>>
>> Let me check if we can move the ID assignment earlier, to reduce that
>> risk.
> 
> I will look into it. Knowing a problem and reducing the risk is not
> good enough.
> 
>>>
>>> 1000 being the first "user" is more a convention than something you
>>> can rely on for any host. (/etc/login.defs UID_MIN/MAX etc.)
>>
>> We are talking about transferring the ID's from the host Debian to
>> the buildchroot Debian - is there really a realistic risk of friction?
> 
> Now you are assuming that everyone is using your container ;). While

No, this is not about the container. We already solved the problem for the 
container long ago (by aligning IDs). This breakage is about the host (in the 
container or on your host) and the buildchroot.

> this is helpful i would like to allow anyone to build without docker,
> given they have a few debian utils on their machine.
> 
>> If we can't solve that sync problem, we need to revert to running as
>> root, I'm afraid. The current model is broken.
> 
> I will send a follow up patch ... maybe today. The reproduction build
> is already running.

TIA!

> 
> Did you see it in any other package than u-boot? Maybe the u-boot
> recipes are broken? I still do not see how a file formerly owned
> by root:root can cause problems as 1000:1000 ... but i guess i will
> understand that once i can reproduce.

U-boot is exposing it, but you see the breakage earlier by getting funny UIDs of 
the artifacts after running a dpkg build.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux