From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6622136737823981568 X-Received: by 2002:a50:cb87:: with SMTP id k7-v6mr2323133edi.1.1542026051632; Mon, 12 Nov 2018 04:34:11 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a50:f5f5:: with SMTP id x50-v6ls1949908edm.1.gmail; Mon, 12 Nov 2018 04:34:11 -0800 (PST) X-Google-Smtp-Source: AJdET5eb3IvFOeDlr3AzQNZgNL+0KJFc2Zc/ZpPRgw8EAPgBcmWs5YmuPs/pCR8ODtCk0VfvUNvC X-Received: by 2002:a50:cb87:: with SMTP id k7-v6mr2323125edi.1.1542026051124; Mon, 12 Nov 2018 04:34:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542026051; cv=none; d=google.com; s=arc-20160816; b=pZIq6mUwLLQOq8mfMoqNtkfLk+O/e1948MISoSA9l+LtFoZSCH9Uk4mJlNV8V4A0mP xQEVGmPtgCxTEO1MSlr2LKzoCqTKvui9swFWJke8f7kR1l7vSZviexS67YR4RtXCnego NI+svxDOIdwWO2dAxRSUCZpXNfKKFrkQOLE2i8FtyzUap4GApgWrtm6n2Kg0kdQfrN/f 4pmkG0gdea1E1CGJQ9Nk51KmT6y7ZEdKrUChCXbfPmMHNnqN+GUfFzRxUgGwvTzIVKrw gIKzaEjDY7ygfx8eDqQckO/42S2s2J/DqD7/oKw8NVnUzkkjuybfgjqzWhqKzZtdHtLg A8Eg== 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=oV1dyt/KwO3+VTL+hwMXOb3AlzaHFhaaTcwj0/chUGM=; b=VhQgkh940AyGBnKB/w7li8VnpaCvzaeNDfsKBtViFR7l/R9YCxYzeXEL0z5qAP700Q mLys+pv0w5ldSS7Ums95Jqjwfi/8tM/Vh8J4RsVX4Dy1SMsZyr+4Bi+6Ti6AfYlld3E9 nqC9iRTi9IrCv3e8aiuTO0Szfj4Xyt03NiXCfQxy3awZoaoAQIrtXxdl9uVNAqjYRrv3 qZlLSck7A81oDuWYlwL7xEYxWJIXOY1SZfhSh8IUukugnJvC1DoYC3WTMNfdUkTUNX2U ArOn7mWD6zySPA7ZBwPScBPJtoad1v1f45WwueTS91JFgNw0ImzKWpp+hSW9LQWnRAdG 3xTA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=henning.schild@siemens.com Return-Path: Received: from david.siemens.de (david.siemens.de. [192.35.17.14]) by gmr-mx.google.com with ESMTPS id m25-v6si435834ejb.1.2018.11.12.04.34.10 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Nov 2018 04:34:11 -0800 (PST) Received-SPF: pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.14 as permitted sender) client-ip=192.35.17.14; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=henning.schild@siemens.com Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by david.siemens.de (8.15.2/8.15.2) with ESMTPS id wACCYAW8024261 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 12 Nov 2018 13:34:10 +0100 Received: from md1za8fc.ad001.siemens.net ([139.25.69.119]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id wACCYA5i029760; Mon, 12 Nov 2018 13:34:10 +0100 Date: Mon, 12 Nov 2018 13:34:09 +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: <20181112133409.4ffa877b@md1za8fc.ad001.siemens.net> In-Reply-To: <3b6545c8-e765-5ac6-56b6-da0fbe7ba9e9@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> <20181112125836.370607f1@md1za8fc.ad001.siemens.net> <3b6545c8-e765-5ac6-56b6-da0fbe7ba9e9@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: FC+id673WMDq Am Mon, 12 Nov 2018 13:11:42 +0100 schrieb Jan Kiszka : > 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. Ok it is a hack that is working smoothly. The need to do that indicates a problem and implications on the host. (and the problem is chowns from two worlds) > > 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. My patch repaired my other patch. Solving the other - long standing - issue in another story. > 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. As long as there is at least one file owned by root, you will need to be root on the host. And by host i mean where Isar called "sudo" for you. While you probably are talking about your docker/file server. In order to deal with those files, we will just need a "sudo" enabled clean target on the host. This way your file server should not see any root-owned files anymore. "rm -rf out/" -> "docker run make clean" Henning > Jan >