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

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

On 12.11.18 12:58, Henning Schild wrote:
> Am Mon, 12 Nov 2018 11:09:27 +0100
> schrieb 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.
> 
> If the container has aligned IDs that was a hack as well. I guess for
> the same problem i just found ....

No, this is working smoothly for quite a while now, also in many CI setup, 
because we control the container content and the fact that there are practically 
no ID overlaps. It is a mandatory feature there, for the same reasons like here.

> The problem is a "chown -R" in do_unpack that brings the hosts uid into
> the chroot.
> That should be fixed properly some day ... i just sent a workaround
> patch.

I'm rather in favor of a proper fix to the ID mess than more working around it. 
The benefit of going for the calling user ID would be - if implemented properly 
- that we will have less files owned by root or some other users unknown to the 
build host, and can therefore only be purged by means of sudo.

Jan

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