From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6622136737823981568 X-Received: by 2002:a19:9652:: with SMTP id y79mr82502lfd.8.1542023918690; Mon, 12 Nov 2018 03:58:38 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a2e:4a09:: with SMTP id x9-v6ls648575lja.18.gmail; Mon, 12 Nov 2018 03:58:38 -0800 (PST) X-Google-Smtp-Source: AJdET5fxXG49K+n6/B9loNBYDnsX7zUuMnIjFEXS/FsND3t8r/GeLYdsodhrn3sFoI0x9sR1dkPu X-Received: by 2002:a2e:90c8:: with SMTP id o8-v6mr90054ljg.24.1542023918081; Mon, 12 Nov 2018 03:58:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542023918; cv=none; d=google.com; s=arc-20160816; b=x4QMYrNHvfik3YlOPh77as6CVeJQ6bMapS2T7MPBOObfpQyVcSS/ZhyGgevtQ2A3Js di5jkihUMjY3PYJeiPvPpcJgLafODN948EFALFKWvWhu69eh9Qqbhk78YzKb1ECDbIPd hmaUccnvsDTYFMXbqBbNdCl6VzqH+AuiMM3DgiI0qZmLoAWOKUEbiQZLTGnvyGz7KNst o5xr2oIlj1hc2W2ImviSbtxJQQa/SWqKHYUgES8HVJTOivGXaP04szaq5ZgA1swDwE5A Jo1D1e/HOvh3MarPRhV3/CZLwKlWN/EdpLCA/YsiwTaWHe+XlSofI8amP2Ix2TsVMKv4 ZxnQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date; bh=tJ0N0r0CH4Wd76AYMJVHF/XxJDK0T1k+FPAbkGvxtj8=; b=grJ4PjIcbaWNLR7x83Ui7yyBb+1bna12wfT+Ctdh9tTe3jO58n+oZ/M8XIViyxO++D SudT9pyTo0kJzSyGZt92PLdnOfTAtSyYldNKYrrgqLYR/6wMUoBDJ68S089rMJva5QR1 VVV7Mu3xIM+rqckPOYnInRPf7B59NTt/6bwL24WarYofDH9t8lqMjGHJVqsF8zRpBcHw Pq0PCTKD8aZUI0LWOsm4PO4D80eQ9D3+wz5i1/16FECeLZeUNJUz2n/QHYXQeiNJluny bxyVhTanRt8Zu5VjCvC5KIkM5lJdEyPGazQFYR3hc/qfZf9eaAlPzjzthnVj0fBUV6h2 BZNw== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=henning.schild@siemens.com Return-Path: Received: from goliath.siemens.de (goliath.siemens.de. [192.35.17.28]) by gmr-mx.google.com with ESMTPS id y18si182275lfe.3.2018.11.12.03.58.37 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Nov 2018 03:58:37 -0800 (PST) Received-SPF: pass (google.com: domain of henning.schild@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 henning.schild@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=henning.schild@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 wACBwb2P028623 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 12 Nov 2018 12:58:37 +0100 Received: from md1za8fc.ad001.siemens.net ([139.25.69.119]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id wACBwaej004065; Mon, 12 Nov 2018 12:58:36 +0100 Date: Mon, 12 Nov 2018 12:58:36 +0100 From: Henning Schild To: Jan Kiszka Cc: isar-users Subject: Re: [PATCH] buildchroot: Align UID and GID of builder user with caller Message-ID: <20181112125836.370607f1@md1za8fc.ad001.siemens.net> In-Reply-To: <0cae7837-9c01-d87b-dd65-851c670caced@siemens.com> 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> X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TUID: o/bqYpFJ2z/2 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 .... 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. Henning > > 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 >