From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6622136737823981568 X-Received: by 2002:a1c:5609:: with SMTP id k9-v6mr2145401wmb.20.1542025657055; Mon, 12 Nov 2018 04:27:37 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a1c:8884:: with SMTP id k126-v6ls1741454wmd.19.gmail; Mon, 12 Nov 2018 04:27:36 -0800 (PST) X-Google-Smtp-Source: AJdET5fRyAaW5bQ1pvPBv1/dPAdSxLeKh/5s8eF3+kxXb5/pag4Fg5m+zt+jf2W5NzFwsf9X2KsH X-Received: by 2002:a1c:6e11:: with SMTP id j17-v6mr2206986wmc.0.1542025656555; Mon, 12 Nov 2018 04:27:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542025656; cv=none; d=google.com; s=arc-20160816; b=bI7UcPeiHNePAgJzUOhSKJ75ql3V35YqpAvD1rn4rrrzm9MRgD83KfaI1zyViu1KxU RCCYxwMRgi/rY9+AJbnqfscM6Sv+w5ooEyQF6z7f1r1n+pCjdpb/tFWvI04yeqtmbe2o bD9+YDqq4b1GuVxRlbizjGwJRfY8EFFRVCow9M+jBpv2NXk8RMBu7DOutGLwB9bcgxhQ f9pUp9EGxHPlIfok0ZWJgBIQvb4XjrzRoqE4qOo2KZGguPxNULKAIREqRskIrQpGCeTV n/Amr41veB187wwWvpXPJ8xgfj9Gx8tbF1kfwgAqwOP+n/ILvDehyHVYe0RrYmlV2zxX LxNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:references:cc:to:from:subject; bh=F2utjO+MBzLz/MAEM2yBD6sYtVe6K9AqRy/rcdlN9Q4=; b=Mr7FvK/icpki15qEIQ5FvVOW7530wfqYp1Q4wzpNRe8ir2q57M1N/itHca7nq7vYjH VnvV4a+SI/EKaRF4Gknqg9gqb7gBx6otmdU6xcJlHlIp44iGL8MveKXUC/pkvOMk6ytP lhhlJMDxIxhQkJmWzFQO4hHS5jQpTkQNdeIBlhtxIIklWoVIvc0EqRfs85zvWtMdx1Hr 7JDSWnWilwtIPNQaWx298dznSW0J/tgsCaXPO6WQ3EtCXUp/Us/65w6sMaSDwOoJor8m W/VNMLYig+sLat59TVves/WkylCtMNgdSWXyFYl6k6ewQMMqPNjPQ1bQE+6h+/J6Uje1 fSpQ== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.40 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com Return-Path: Received: from gecko.sbs.de (gecko.sbs.de. [194.138.37.40]) by gmr-mx.google.com with ESMTPS id v6-v6si547236wrn.0.2018.11.12.04.27.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Nov 2018 04:27:36 -0800 (PST) Received-SPF: pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.40 as permitted sender) client-ip=194.138.37.40; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.40 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by gecko.sbs.de (8.15.2/8.15.2) with ESMTPS id wACCRasf021036 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 12 Nov 2018 13:27:36 +0100 Received: from [167.87.36.55] ([167.87.36.55]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id wACCRZ23009218; Mon, 12 Nov 2018 13:27:35 +0100 Subject: Re: [PATCH] buildchroot: Align UID and GID of builder user with caller From: Jan Kiszka To: Henning Schild Cc: isar-users References: <0ec8a678-7297-4ad9-4a9b-49d87f504061@web.de> <20181112101648.051ce0ed@md1za8fc.ad001.siemens.net> <680671b8-2c63-3447-ca15-35431178b266@siemens.com> <20181112104255.464bdf54@md1za8fc.ad001.siemens.net> <7acfa387-b037-af81-82a3-748edd97c008@siemens.com> <20181112110625.1f55f7a5@md1za8fc.ad001.siemens.net> <0cae7837-9c01-d87b-dd65-851c670caced@siemens.com> <20181112125836.370607f1@md1za8fc.ad001.siemens.net> <3b6545c8-e765-5ac6-56b6-da0fbe7ba9e9@siemens.com> Message-ID: <51a426a6-c057-ada1-6d26-d9f7e31b27c4@siemens.com> Date: Mon, 12 Nov 2018 13:27:34 +0100 User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 In-Reply-To: <3b6545c8-e765-5ac6-56b6-da0fbe7ba9e9@siemens.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: YmrPcyNO3i// On 12.11.18 13:11, Jan Kiszka wrote: > On 12.11.18 12:58, Henning Schild wrote: >> Am Mon, 12 Nov 2018 11:09:27 +0100 >> schrieb Jan Kiszka : >> >>> On 12.11.18 11:06, Henning Schild wrote: >>>> Am Mon, 12 Nov 2018 10:52:22 +0100 >>>> schrieb Jan Kiszka : >>>>> On 12.11.18 10:42, Henning Schild wrote: >>>>>> Am Mon, 12 Nov 2018 10:19:54 +0100 >>>>>> schrieb Jan Kiszka : >>>>>>> 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. Actually, also 624b7c484bf5 could be reverted if we managed to align IDs... Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux