From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 7002935164998254592 X-Received: by 2002:a05:6512:3458:: with SMTP id j24mr1863389lfr.366.1630574267492; Thu, 02 Sep 2021 02:17:47 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:ac2:55b7:: with SMTP id y23ls335007lfg.1.gmail; Thu, 02 Sep 2021 02:17:46 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzpdKqCg7vodunKlG+ZYXcqTViReV/zgDMrNA4G5yWPwfJFCMfq/fu+5pyFiOnjbSI/CgpC X-Received: by 2002:ac2:46ec:: with SMTP id q12mr1860896lfo.51.1630574266301; Thu, 02 Sep 2021 02:17:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1630574266; cv=none; d=google.com; s=arc-20160816; b=0nF5eLedODgQoANtRzMUBgLN54jIxBvL88SMFWA0pKw2iIKBDMB5Akx+/O7JU0eE+t Wp/MSQfHUyyzZ5hkYVdThUy3nETXv1/Rr2KZSrqdj7lP2JeQarMbI0O0qQb2kouJJL0Y rimIPqgI7LZam3cJNq/X5JwuN3j0aweemimFg5FiqynVT+S/8fRPFMhli35ZbKVswxev mwrYPtLrLrUzPxAUGT0TVc4c2gnw27v+vIoy6mHP+qLRZC1cOqGkI4Mf6UkQf5YurpD3 rHIVdeMUDei7ycpp/2xtSLo5dduDX+yexsP/1qLTTUMECOuvFUkXu8eK2daL5AK2Ravu EzKA== 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=CFTMqsXteOT0kK4cxpjdEgkkAgSmlh/BXirUqa4SYb8=; b=kQLIlB8lSBkYBZR1/ZIFT7sdEps8v3JqqsVpQwTqkOOQQzPP+dS2o6dVhByGKl4TPi YQDlYCFjHsYr1R0Qg9P7PM8LX8mjbX/aGqPx6ldSiS1Z3jrIft5VHMT1t1o7U32IvOXc OOTRiGWj+j7Xr9DDcc8jFgdzXPHDma9O0edGz1y0vGkFRw17mwhavVFPeydcwxEuF0ii WbYe5eeyG3iBEofC/ZlcVoQMGBI6+H+hautEQhvQoDuaNkUYzTiZKzfr1PhLr2mD4ZRP lP47W9m13Y9KG0iXLlNQzFVZGFdV45yieKit+lkeo+T8KT/SRWzkmQaEvDpUEke/t89O 8hpA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 194.138.37.39 as permitted sender) smtp.mailfrom=henning.schild@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from lizzard.sbs.de (lizzard.sbs.de. [194.138.37.39]) by gmr-mx.google.com with ESMTPS id i12si62121lfc.10.2021.09.02.02.17.46 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Sep 2021 02:17:46 -0700 (PDT) Received-SPF: pass (google.com: domain of henning.schild@siemens.com designates 194.138.37.39 as permitted sender) client-ip=194.138.37.39; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 194.138.37.39 as permitted sender) smtp.mailfrom=henning.schild@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by lizzard.sbs.de (8.15.2/8.15.2) with ESMTPS id 1829Hj7d019275 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 2 Sep 2021 11:17:45 +0200 Received: from md1za8fc.ad001.siemens.net ([139.25.0.59]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 1829HjRi029579; Thu, 2 Sep 2021 11:17:45 +0200 Date: Thu, 2 Sep 2021 11:17:44 +0200 From: Henning Schild To: "Schultschik, Sven (DI PA DCP R&D 2)" Cc: "isar-users@googlegroups.com" Subject: Re: Fixed user ids Message-ID: <20210902111733.02f82926@md1za8fc.ad001.siemens.net> In-Reply-To: References: <20210901175433.2b76961a@md1za8fc.ad001.siemens.net> X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-TUID: KnLqw3cCk26G Am Thu, 2 Sep 2021 10:08:15 +0200 schrieb "Schultschik, Sven (DI PA DCP R&D 2)" : > Hi Henning, >=20 > true, but the problem is different. > A little bit OT to understand the reason. > We have a A/B firmware update with a third partition which contains > the /etc as overlay. Ok understood. The proposed solution does not always create the same uids and a build is not reproducible. > Now the passwd is saved in third partition with the UIds of the V1.0 > With the V1.1 two services and accounts are added. Now the build add > those new accounts and shift a lot of userids around. If you do then > a update from 1.0 to 1.1 the passwd from overlay overlays with > different Uids. >=20 > A big migration script is not a good way too, so some sort of fixing > some of the ids would keep the compatibility. I think a migration script would in fact be a clean solution. It could be a postinst to your swupdate and "chown/chmod" a few times. If that would end up "big" you probably have a "bigger" problem. In fact that script could call the actual postinst scripts of your "chowning" packages. If you really want to go down the road of fixes ids you can probably create a package which conditionally creates all users with fixed ids. You make all users DEBIAN_DEPEND on that and try to make sure it gets installed pretty early. But if the debian base decides to claim one of "your" ids you might be pretty much out of luck. Say 42 is free in stretch but "suddenly taken" in bullseye. My feeling is that fixed ids with a postinst of a package that gets installed "very early" might be possible. You can get super-early by finding a package in the bootstrap-set and appending a "Depends:". But cleaner would be to let users be created with "random" ids and deal with the chown in postinst and using swupdate in a similar postupdate. regards, Henning > Regards > Sven >=20 > -----Urspr=C3=BCngliche Nachricht----- > Von: Henning Schild =20 > Gesendet: Mittwoch, 1. September 2021 17:55 > An: Schultschik, Sven (DI PA DCP R&D 2) > Cc: isar-users@googlegroups.com > Betreff: Re: Fixed user ids >=20 > Hey, >=20 > pre-fixed user ids would be an anti-pattern and would only work if > debian would do it. >=20 > If you need files to be owned by a specific user you chown and > possibly chmod them in postinst. Using the name and not an id. You > create that user in case it is not already there. >=20 >=20 > https://github.com/ilbers/isar/blob/master/doc/user_manual.md#home-direct= ory-contents-prefilling >=20 > and here the example postinst >=20 > https://github.com/ilbers/isar/blob/master/meta-isar/recipes-app/example-= raw/files/postinst >=20 > This is also how debian does things. i.e. when a webserver needs the > user "www", all web-server packages would create that user if not > there, and chown/chmod based on the name. >=20 > I think every file in a debian package will always belong to > root:root, and deviations need to be chowned in postinst. >=20 > Henning >=20 > Am Wed, 1 Sep 2021 12:04:57 +0000 > schrieb "Schultschik, Sven" : >=20 > > Hi ISAR users, > >=20 > > =20 > >=20 > > I=E2=80=99m currently thinking about to freeze the users and group ids. > >=20 > > =20 > >=20 > > I have different ideas in mind, but I wanted to ask which would be > > the best way with ISAR to generate fixed user and group ids. > >=20 > > =20 > >=20 > > Or do you just pre create all needed user accounts before installing > > the packages within the build process? > >=20 > > =20 > >=20 > > Mit freundlichen Gr=C3=BC=C3=9Fen > > Sven Angelo Schultschik > >=20 > > Siemens AG > > Digital Industries > > Process Automation > > Software House Khe > > DI PA DCP R&D 2 > > =C3=96stliche Rheinbr=C3=BCckenstr. 50 > > 76187 Karlsruhe, Deutschland > > Tel.: +49 721 6672-0128 > > Mobil: +49 162 4975705 > > > > mailto:sven.schultschik@siemens.com > > www.siemens.com > >=20 > > Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Jim > > Hagemann Snabe; Vorstand: Roland Busch, Vorsitzender; Cedrik Neike, > > Matthias Rebellius, Ralf P. Thomas, Judith Wiese; Sitz der > > Gesellschaft: Berlin und M=C3=BCnchen, Deutschland; Registergericht: > > Berlin-Charlottenburg, HRB 12300, M=C3=BCnchen, HRB 6684; WEEE-Reg.-Nr. > > DE 23691322 > > =20 >=20