From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6622136737823981568 X-Received: by 2002:adf:b598:: with SMTP id c24-v6mr164169wre.0.1542024705268; Mon, 12 Nov 2018 04:11:45 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a1c:85d5:: with SMTP id h204-v6ls1780209wmd.19.canary-gmail; Mon, 12 Nov 2018 04:11:44 -0800 (PST) X-Google-Smtp-Source: AJdET5coo2MHi1L3KkTupbUz7uhGzLhnO2tka4TVdf1TxYzq0iiyYYC/Eqx10ZOVhFH1dKLIfKhL X-Received: by 2002:a1c:23c8:: with SMTP id j191-v6mr2250855wmj.0.1542024704731; Mon, 12 Nov 2018 04:11:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542024704; cv=none; d=google.com; s=arc-20160816; b=TtMoT9yMvFcBwWxRc1v8QCdq9R+Cucae5rZjHUeS7Fb95ftp3gXmCJjh7EFh1OIlbi pGiBKW50vJRp35bK/NCUWfcsv4E0L/+1YKeQMUWlnF/D3hy6bPjAT07kmZrxXsTxQLSW bLjfdyK3nce4OwWl44E/KrLJuDfo7bEWVsbDvBwnJ+BXyUuxslOgpc5e2SygAvR4P57e w+RE48mVO4nPf2osQIn5r4PyPkH/lfLgt8O+NhSq3Vh6P0xg+2NoNfljbnFdKKwLLSgM egLqeoFcME08J3wrJKGYEVvKCz/L7SMoqITIjuUCjzqy9zHb6/6H14/PNdRZStDfBa81 HXbw== 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:from:references:cc:to:subject; bh=5PU1a9VRCFcarEnDZbB/b9PuLETxIN8+3HYlz0fdLzk=; b=GyXpnXAaAV/X8y1bmSt6yMQ+MTnVtO5E+RWnr8kH/yxhNzF/RrXHbM/7ZHi4fiQV2M FsphC8h4Y6rTHsDlrzh2C3sYApuMwghTrfEsNwIZVNPD1hEXU4L4vnx6IwTyJG36bwWW JCRi0P25jF/qog3m8VuqPlCNP8Lz0On5OO/zCJtL/I/hZk7YkhCSPn7WyGNYIc9mYC4/ xZDJHQWCkunoHdd8rf307UdPRcA/C97js1CHIiP+yio/7HlQIyo+8EUrcAveqpeYJTk7 HX4/FFlFsbw47Um2ZGQ40vjQJ34bLiEnWk58Dz0RQUFXEeQYF8OaierCt+59MFJxaK5p XEgg== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com Return-Path: Received: from goliath.siemens.de (goliath.siemens.de. [192.35.17.28]) by gmr-mx.google.com with ESMTPS id 191-v6si353319wmv.0.2018.11.12.04.11.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Nov 2018 04:11:44 -0800 (PST) Received-SPF: pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.28 as permitted sender) client-ip=192.35.17.28; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id wACCBi8m020420 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 12 Nov 2018 13:11:44 +0100 Received: from [167.87.36.55] ([167.87.36.55]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id wACCBhXq018514; Mon, 12 Nov 2018 13:11:44 +0100 Subject: Re: [PATCH] buildchroot: Align UID and GID of builder user with caller 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> From: Jan Kiszka Message-ID: <3b6545c8-e765-5ac6-56b6-da0fbe7ba9e9@siemens.com> Date: Mon, 12 Nov 2018 13:11:42 +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: <20181112125836.370607f1@md1za8fc.ad001.siemens.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: uhcO+ZK/iY17 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. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux