From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 7192512605249863680 X-Received: by 2002:adf:a1db:0:b0:2bf:b410:1790 with SMTP id v27-20020adfa1db000000b002bfb4101790mr358295wrv.191.1674728829770; Thu, 26 Jan 2023 02:27:09 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a05:600c:3d06:b0:3cf:9be3:73dd with SMTP id bh6-20020a05600c3d0600b003cf9be373ddls2630585wmb.3.-pod-canary-gmail; Thu, 26 Jan 2023 02:27:08 -0800 (PST) X-Google-Smtp-Source: AMrXdXszRYNYyKB+koBBCWUpQDgHmjJsz1Jj/JKGetYrdfsnEMy0Na5jionkXxDeUiCX6BTY9JdM X-Received: by 2002:a05:600c:601c:b0:3d3:4f56:62e1 with SMTP id az28-20020a05600c601c00b003d34f5662e1mr34971434wmb.27.1674728828616; Thu, 26 Jan 2023 02:27:08 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1674728828; cv=pass; d=google.com; s=arc-20160816; b=noUVc8dC49viO0mnmQA0lr+Uspn9+0GlP24V/yNZclTlTSMQvyFQ2/w6Mi2JN4WksJ XLhR7L+S2oxOjZQEizYvSQyBu1w/ASev/KKckz62vmwr4S5jwfwAUmxrr61dWF/dvJy0 5QeLIMxlhxU5eXm0wPlcalqGnqZKkaFdyAmJlPItHvyEccYAUhELRw/JgbwA0/nCBDEH 2fg/lHwVEo/xp+extv2Mj9rwYDSZPph+YDpH5gDrS3Y+7y05QT3oevhkjV3au6eauVzY yFZnlikzzTW8f3TTc8aqerp1e4/5hJcKAv88bPmaeLe6nTiDBySf/RWMRha2yhCqIb5R U1GA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:content-transfer-encoding:references:in-reply-to :message-id:subject:cc:to:from:date:dkim-signature; bh=yyWXQ4VTbt5rA2On7KLJztXVBAIRAX2XyL0Gb1xN+38=; b=eC9bJz2I5aXLeodSFRuVMu3/0bdzN+plPfPUhdE84tTWJoizIrR02iLgYIT8QZ7enU j9T8azbeofZPvqrwyJI3KUQ41FGadPFi2zgbHETRR7b63ut4MI2bg0RxN//hxoNYyVeB AG1HZG1vGMCMwlDfbdMkgP6QBVuBFatJYiE3m8xF+C/8rfx6gmugThPH1M47zUYDrxTH WjWrf8HEp1eedEiRe+osX/BHwPaiLt4/zceqUg7DWO8PGdIrzh20OzmY320oGZV7KCQU 5e5dqXMzlPnwvEJjbUjEl0SgniXnOfF4U4O8tDrUqYDD45dcNdErKMTFIJ75uN3R0Hfl LPZQ== ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@siemens.com header.s=selector2 header.b=TGcs6GFF; arc=pass (i=1 spf=pass spfdomain=siemens.com dkim=pass dkdomain=siemens.com dmarc=pass fromdomain=siemens.com); spf=pass (google.com: domain of henning.schild@siemens.com designates 40.107.8.82 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 EUR04-VI1-obe.outbound.protection.outlook.com (mail-vi1eur04on2082.outbound.protection.outlook.com. [40.107.8.82]) by gmr-mx.google.com with ESMTPS id ay6-20020a05600c1e0600b003d9ae6cfd2esi61756wmb.2.2023.01.26.02.27.08 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Jan 2023 02:27:08 -0800 (PST) Received-SPF: pass (google.com: domain of henning.schild@siemens.com designates 40.107.8.82 as permitted sender) client-ip=40.107.8.82; Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@siemens.com header.s=selector2 header.b=TGcs6GFF; arc=pass (i=1 spf=pass spfdomain=siemens.com dkim=pass dkdomain=siemens.com dmarc=pass fromdomain=siemens.com); spf=pass (google.com: domain of henning.schild@siemens.com designates 40.107.8.82 as permitted sender) smtp.mailfrom=henning.schild@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=B/va7fX/ozA9Rit/3Z3Jg0klIc425Mld8JhlQCi9Z2xyI5pCp7dwcGe+jGxkvN4XEPDbiulgPYEw9cBt9rMgLVS4KME1QuRn70hGch8vS/3vSGhixpDWIxMVRT581Lq8x3PL1Qpvcs3olTHBVJb7XKbShuNlNFpCtr06qKtupr6D48v7xvnWmO+vHQAJSNordNmd1mc4KrOm/ci7Ux+4cjQg0LmSnshwSCNA1uNc1BbvWRdlOHl1e08jAbqmCAJXowfwYjG6vQ8L7G6mFVueV73qZ8+4qJSby+doyoXh5cBqosOU0700bQLGLJ+7tLr+VeLOSZUqdksQ+/dhUwc+mg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=yyWXQ4VTbt5rA2On7KLJztXVBAIRAX2XyL0Gb1xN+38=; b=IB6CaKItSyAjav3ykxZxxM4CyosEeoMs6CUsKLU2TKrvH4PkzWAf58EMx/uVZGheVvX9rnQw2TBrgNZngd6NzDPJN18YqMVjtKvpB6uWNGf/z7lE749ZB5tlwty1eDeCNmyqdoMxendqdGohaWrcBniUOmNU0+/grTPHykk8TSzBVSmsbYkqViou9HagHPNnR0IMgh4U3KZnIFAkajxTTvaU5dKT/HOrzUanSdbHAMN9YqbAmyd/Kv7iLPsTkX5+LTs3A+qu/MTHCfpWdRaP5PLpWQa5hKi9KH5ueA92mXEl1jd+v61mLB5Rq2TFcjHlwxncPrcvpzsVoFyLr8jYbg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yyWXQ4VTbt5rA2On7KLJztXVBAIRAX2XyL0Gb1xN+38=; b=TGcs6GFFYZ2uL9bwPfBpQ21ITU8ZRGQHyA0VbVV7Qrgfn5WVKbP2GSjakBca3xnDaJPaQBRnvoS4puVoQvxaCTUcjRj0W79qCjGm5W5Pg6knEbsVWfC34CT4ApoFodYbyxR0YOxs2NhD65oD3gEuTnQ0Jm+e5yRq9UiYlCB84AsedTmClsp2LkTP567nBsZvrK03Dp13Pbm8LRcJvcBUYoEVkNlH/U4zejrxjMLjvTdI9CD27w5qh193l0tzBU6g2f1hri9Ywh79BZvaFwZ0CWLuA7uqqhHKmY+fZkfWT1WIeEizyoadfITunuL2K2GqPXBTaS5ZXH0Hn/UXtBBPVA== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=siemens.com; Received: from PA4PR10MB5780.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:102:269::8) by AS2PR10MB6894.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:5f9::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6043.21; Thu, 26 Jan 2023 10:27:06 +0000 Received: from PA4PR10MB5780.EURPRD10.PROD.OUTLOOK.COM ([fe80::bdf0:fdeb:f955:bc79]) by PA4PR10MB5780.EURPRD10.PROD.OUTLOOK.COM ([fe80::bdf0:fdeb:f955:bc79%4]) with mapi id 15.20.6002.033; Thu, 26 Jan 2023 10:27:06 +0000 Date: Thu, 26 Jan 2023 11:27:02 +0100 From: Henning Schild To: Florian Bezdeka Cc: "Schaffner, Tobias" , "Gylstorff, Quirin" , "isar-users@googlegroups.com" , "Adler, Michael" Subject: Re: [PATCH 0/5] allow creation of users/groups before rootfs creation Message-ID: <20230126112702.6ba06a3d@md1za8fc.ad001.siemens.net> In-Reply-To: References: <20230125090156.284309-1-tobias.schaffner@siemens.com> <20230125142901.597613d7@md1za8fc.ad001.siemens.net> <20230125172916.0d49528f@md1za8fc.ad001.siemens.net> <73457b6d-c5cd-7e43-5142-2feab5caa54a@siemens.com> <20230125223848.6b911eb5@md1za8fc.ad001.siemens.net> <1b8a1db2-0390-8027-4a45-471f2385a50e@siemens.com> X-Mailer: Claws Mail 4.1.0 (GTK 3.24.35; x86_64-pc-linux-gnu) Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ClientProxiedBy: FR0P281CA0007.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:15::12) To PA4PR10MB5780.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:102:269::8) Return-Path: henning.schild@siemens.com MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PA4PR10MB5780:EE_|AS2PR10MB6894:EE_ X-MS-Office365-Filtering-Correlation-Id: 3c4b473a-adcb-4b69-2b5d-08daff87df94 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: +qzI+IZA9tw5ApnanI1ATDv9Rj555S+vqjGjh+LEDnpsOaN0mFjM5g6g2gNZoxg8sw+b9tRwrAvypEEakfUxklA0CKTHNbOx1A5yXZILJCruZ2nl2OwOYKRQOo9UrwJTsKg3l0UrqETLQsqJJwZbfCP4CYJrRX+XU7DgbKhrtpyrKfNKJcpjGnbZfBynaZc2Kvr9+yXKMMQWEGwC1FGCarc+0GAEQ9Xn9Jlp1tnrMFxwMG675AiX8AUnipSBC0ildOypmyC3ooEpq+iBTYsYuzISZstF5LZpw7Cwu2yrXwgK5avcpd1VH3FXIzbUhUkT3MzKi8cpl6bFKDj1RqfF9y6TQoboXxhNgpQjM0WjbivB/bXbX9VfdhwT/HG2unoDOpBawleyKSmPI8vb9kaHvbSaGCDkR8+14aji36GAjlxGJZEDKFBGArpCuGfduwXII+rOHFHTy7QWeWF7xdCgkb/g78z17rWPbcPugksQqymZAEWg3LnVRiTar8E7NNyb8BFRgrkdMbVhPsAT3Ad2NLIRIjefLm5f3D6H10Pz1+5iLspYGTxfWHcoR3wC0vnN9kldfLCdmEBigc8j5P7ytwAZfK4//LC4x0q/ORoAEsUTVButzs3hQPCpHcoDuZqxU+2/g2wqC3rtJTY1hLxvU82bqb5SdsUmosnG9LOLjF3kNzGJBdkchr6J/qzao+OP X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PA4PR10MB5780.EURPRD10.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230025)(4636009)(376002)(396003)(136003)(346002)(39860400002)(366004)(451199018)(186003)(8676002)(6636002)(38100700002)(83380400001)(54906003)(6512007)(86362001)(9686003)(5660300002)(966005)(44832011)(6862004)(107886003)(6666004)(478600001)(53546011)(6486002)(82960400001)(6506007)(1076003)(30864003)(41300700001)(66556008)(2906002)(8936002)(4326008)(66476007)(316002)(66946007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?5K+Ie5p75n38fWUQahkNA1/YZGiZdzroSVU8eHu2rlLV3B5DKl8Dz7OhXtxn?= =?us-ascii?Q?zUkdTfUQwuTQpkcol954wvQ6FH9hDNEAai9mYOHrhK/0ax0Ur3SQR8dKFAf+?= =?us-ascii?Q?/OyPmEUZyCjhe91l6OqtqhOjdSbw+MydgU4RG4hIvrPvkRuh0QSDf+/AQiIg?= =?us-ascii?Q?BlmhPRnbqGm7pb0DW6MZcwbcYPrElQELhqMXL1LSV5RnGGVeDHPlM4mRNHtB?= =?us-ascii?Q?0gcS1TVORuoA/FCkmDGdKyTw774jvE2GYaxVMNJ0yLU5FT84f5livw1iq8jp?= =?us-ascii?Q?8dY+k7c2naBQ6arbhNX0weAeQ77VOJsflVmKy9aUHLMOjgyBPd77XnMbeg4f?= =?us-ascii?Q?9gyx62TBATeZ2mmHSumsGPf4XKJBGAlJOeDr0RrSu3x99h2E+WZOAxVer2E6?= =?us-ascii?Q?R4k0B8C92YzM/vMOh7m0vHkiRZTyEdVZ8EvM3VdjPcCuEJaZ1Z9hxtPgrTPI?= =?us-ascii?Q?B77ettSIHMfx8pEP56iKRfUSOQRK/a+vJj1oaETgseAdJmrdeEn/C0VZplEa?= =?us-ascii?Q?Odw2VG+AzyA73Ty1tAxauAyXy3t1EOX6pCtuMdOn3bzc+7ur4f60qZMZZ7F7?= =?us-ascii?Q?XpxgX4ZVFSGcHtk9nGO3Hf/hHXAumey7FfRO4aknmQJmx950c4EiYs5fNhFt?= =?us-ascii?Q?8Y/yFP0MkMLwrtug5f9+ZYU3xmZsP3BfLZRW+mPln1zbKMh/fIapnMA1cwJB?= =?us-ascii?Q?0U54Jm3SiCuk0HMFUMRcgcBQgexmduuBxIwpz16W4I2IEfh/GfTEBtbRSPT5?= =?us-ascii?Q?V0UC1msadeb5qI9XiS0CxtnZOtolWfFlNP/Efi5hwPkv/mGX3s2rfk7hqXgD?= =?us-ascii?Q?Mo0ShS6DLSlVopUEieVwpwTYxukK+m9klPkG3XStmjuY0Q0248SpMSf8u6/Q?= =?us-ascii?Q?azMvBt0HN8ylqSLW5iV5fsklldrpOmZA1NleGC56y9xl8ETSe1z9ixCJuecA?= =?us-ascii?Q?y73+AmZNPV8ySD0EK0pYYwb9HVZofh3r5AtpowRvmlLJriB6l4VS+BXJdens?= =?us-ascii?Q?d3cGvEYdEO5/v56Jzo/3YxWnChXB+Hhlrh/NQWLqL7Tv2YyNJBHcSCr4OLa3?= =?us-ascii?Q?i30DhpHhXexE7zCSTl0kyAvpzI6RpwM5am4P3hSegkQANqC54a5fDX1fk30O?= =?us-ascii?Q?RDVQnzE2fG333hNcuvuy4FZk4HaK9S4wS3Q66upa8fxwMKPa73BEej8lAapF?= =?us-ascii?Q?Wp9KxXL0MOlEs8gDzBzigTpQSW3ZNuuQenZL6Nu+W7+pfOH/cdzjFZwCupGn?= =?us-ascii?Q?eHnSrGV7b2jMLBfhvGvT2p8mLG1wBAZ8n6ma9ozgwhkl9oAFPt4jbtaOIicu?= =?us-ascii?Q?IjRzcAk6gg/nzLHLEvuy4GEfu4aW71BKNqlMHDCn5jmqFGpnE4ecWS1CD/pX?= =?us-ascii?Q?eNTjeGAVpgVaK5unMdPB+jFayhEDkZWCDfOpXGXMIu6InbgtINN3aijNrhR1?= =?us-ascii?Q?gri1I74Vb7Ml/2dsGY9mFXg2WlP64WcDMXGUmc6DY05ZqG20Y2CFk6KU9pQT?= =?us-ascii?Q?mspQOshT/kK4wt9nUaliYWRCBawe11YiVVs5+akv2FH048Cx7rqcusGl3w8x?= =?us-ascii?Q?7yW/tYHzhIxKK7QJkqMH7F+BZVNJiaKRECm1rZhu0BMOcYwv3eQ3yQy3MiDz?= =?us-ascii?Q?zxSD9D6u/yo0my9Rl61Z5WimziYMBz5CZt8HEJyS+GiF/WIeRKdYnVMZhWsE?= =?us-ascii?Q?876clw=3D=3D?= X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3c4b473a-adcb-4b69-2b5d-08daff87df94 X-MS-Exchange-CrossTenant-AuthSource: PA4PR10MB5780.EURPRD10.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Jan 2023 10:27:06.4606 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: +xx4/qLJA1xWAARejo5BPHFvJ23qRAIpBGBnvQpUrc5UyPPlZCzU9YllOVTvwQO16eOb+F5bjkrY98WHAt/f533mX0Po+I+ooGfLuph+nms= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR10MB6894 X-TUID: 33mA7VmXvqKj Am Thu, 26 Jan 2023 09:48:06 +0100 schrieb Florian Bezdeka : > On Thu, 2023-01-26 at 08:21 +0000, Schaffner, Tobias wrote: > > On 25.01.23 22:38, Schild, Henning (T CED SES-DE) wrote: > > > Am Wed, 25 Jan 2023 21:55:00 +0100 > > > schrieb "Schaffner, Tobias (T CED SES-DE)" > > > : > > > > > > > On 25.01.23 17:29, Schild, Henning (T CED SES-DE) wrote: > > > > > Am Wed, 25 Jan 2023 14:44:40 +0100 > > > > > schrieb Gylstorff Quirin : > > > > > > > > > > > On 1/25/23 14:29, Henning Schild wrote: > > > > > > > Am Wed, 25 Jan 2023 10:01:51 +0100 > > > > > > > schrieb "T. Schaffner" : > > > > > > > > > > > > > > > From: Tobias Schaffner > > > > > > > > > > > > > > > > This patch series will allow to specify a `pre` flag > > > > > > > > for the USER_ and GROUP_ bitbake variables. If this > > > > > > > > flag is set to `true` the given user or group will be > > > > > > > > created in the rootfs configuration step instead of on > > > > > > > > rootfs postprocessing. This is helpful when a specific > > > > > > > > id should be used which would otherwise be picked by a > > > > > > > > user or group created by one of the installed packages. > > > > > > > > > > > > > > > > > > > > > > While i do understand the reason i am not sure how > > > > > > > relevant that is. Why would anything only function with a > > > > > > > fixed ID? Whoever provided that thing should maybe fix > > > > > > > it. > > > > > > > > > > > > Specific IDs are necessary for Updating an A/B rootfs > > > > > > system with a persistent partition. In this case you do not > > > > > > want to change any IDs as this can lead to wrong file > > > > > > permissions. > > > > > > > > > > I see, that is much more understandable. It also goes into the > > > > > reproducible build direction. > > > > > But if that is the case the solution does not seem to be good > > > > > enough because it only considers users/groups created by > > > > > isar. Not the ones created by installing debian packages. > > > > > Where the order could be potentially random. Say you > > > > > DEBIAN_DEPENDS or IMAGE_PREINSTALL "ftpd wwwd" which will > > > > > craete users "ftp www" where the two deamons do not have any > > > > > dep on each other and apt-get could install them in any > > > > > order. That order might in reality not change too often but > > > > > it could i.e. when you move from debian11 to debian12 or when > > > > > you bring the third (or 10th) user-adding package into your > > > > > new firmware. > > > > > > > > Thanks for the review! > > > > > > > > This series is not about reproducible builds. The IDs of the > > > > users and groups that are created by debian packages are > > > > expected to change between _image_ versions. So we expect these > > > > IDs to be different after a swupdate. > > > > > > But your initial argument was that you have to create a user > > > before any debian package comes, or did i misunderstand? Maybe we > > > need to differentiate between upstream packages and isar-created > > > ones? > > > > Lets make this clearer with an example: > > A downstream layer creates one user X that writes to a separate > > partition. This user gets the ID 1000 as there are no packages that > > create any users. > > > > Now they want to create a image update that should be deployed. > > The updated image includes a new debian package that creates a user > > Y. The user Y of this package gets the ID 1000 as it is now the > > first user that is created. > > > > User X will now get 1001 and it is not possible to change this. The > > data created on the separate partition belongs to user Y. > > > > The only resort at the moment is to revert the patch that moved the > > user creation to the post processing. > > Hm... I have the strong feeling that your approach is broken in the > same way... > > I was questioning myself how Debian itself solves this problem. The > answer is: Debian has access to the "old" or "current" user database > while doing updates. So it can not happen that a user gets a different > UID. We would have to feed in the "current" user database during such > updates to do it the same way. > > Why your approach is broken: Consider three image versions A, B and C. > There is no guarantee that someone will update from A to B and then to > C. A -> C is also possible. > > Image A can add a user using your "pre" logic, B can remove that user, > C can introduce a new different user, but with same ID. That brings > you into the same situation. Whether a firmware update supports skipping intermediates is up to whoever builds a product. Interface changing releases should always support old and new interface. And at some point one can drop the old. The most trivial/conservative implementation would be to make any update a stop-release which has to be taken. That greatly reduces the testing effort and you have to think less about interfaces. But it can lead to a bad user experience if you have to update too often because you can not just jump. Henning > As Isar can't tell if that is a dangerous scenario for all the > possible use cases it's a NACK security wise. > > > > > > > > For reproducible builds it is important that the ordering of > > > > installed packages and their dependencies stay the same but > > > > that is a different story. I expect the ordering algorithm for > > > > a specific set of packages including dependencies to be > > > > deterministic but would have to look into that in detail. > > > > > > I expect the algorithm to be non-deterministic ... potentially as > > > you progress using debian. I can just claim, you have to prove. > > > > From my point of view this problem derives from the fact that the > > set of installed packages will change on image updates. If the user > > Y is created in the first or in the last package does not matter. > > Its just the fact that an additional user gets created. > > > > > > Still, if somebody had a requirement that a user or group of a > > > > package (e.g. ftp or www) stays the same, one could use this > > > > change to create the user beforehand and pin its id using this > > > > change. > > > > > > True. But we might still want to keep the old database to run > > > assertions so such things do not go unnoticed. > > > > > > > > So what you maybe really want is giving isar an /etc/passwd > > > > > /etc/group pair. Every new firmware is build with the given > > > > > layer code and that file-pair from the first release. Where > > > > > you inject those files between bootstrap and install ... > > > > > hoping that bootstrap will always be the same. Maybe one can > > > > > inject before bootstrap ... or write a postproc function that > > > > > will find all different ids and all files and fix up. Or at > > > > > least start with an assertion in postproc that looks at the > > > > > old database. > > > > > > > > Care that just adding /etc/passwd and /etc/group might not be > > > > enough but you would have to handle the side effects of a > > > > useradd/groupadd call properly (E.g. creating the home if set). > > > > And I expect more things to come up if you have a detailed > > > > look. > > > > > > Yes. Not even want to think about LDAP or yp where the databases > > > live in different files. > > > > > > > Take into account that the specific patch that introduces the > > > > pre flag is small, easy to maintain and configure. > > > > > > It should still be motivated so that we later understand why we > > > have it. And i would not call it easy to configure if one does not > > > understand why ... people will "pre" randomly because they do not > > > know what they are doing. We moved that stuff from pre to post > > > once, and i can not help the feeling that people might want to > > > want to mix pre and post one day ... at which point it might > > > become really un-easy. > > > > > Is the problem of uid/gid depend on install order known in the > > > > > debian community and how do others solve it? Gentoo has moved > > > > > from such dynamic allocation to static some years ago, > > > > > probably for similar reasons. > > > > > > > > I am open to discuss this with the reproducible build guys but > > > > again IMHO this discussion belongs into another thread. > > > > > > IMHO not, the repro guys want full repro ... which we can happily > > > leave out when it comes to me. You want partial repro, which we > > > should discuss here. > > > > I think you may have a valid point that a non deterministic > > ordering on package install may be a problem for reproducable > > builds. Not only when it comes to users but also e.g. every time > > two packages append to the same file. > > > > > I do not want to hold this back, just understand it and see if > > > there can be a better solution. Feel free to ignore me and merge > > > if nobody else asks questions. > > > > I am happy to discuss this, I just think we are mixing things up. > > But maybe I am missing something. > > > > Best! > > > > > Henning > > > > > > > > Henning > > > > > > > > > > > > > > > > > > > So i am willing to say that this is super-niche! And it > > > > > > > deserves a niche-solution in its layer, not a feature in > > > > > > > Isar. > > > > > > > > > > > > > > You could hook in a task between bootstrap and > > > > > > > image_install. Or you could rebuild a bootstrap package > > > > > > > to have reserved ids. You could run "the thing" in > > > > > > > namespaces ... > > > > > > > > > > > > > > So is that really relevant? Please go into detail. > > > > > > > > > > > > > > Whatever happens i think the python rewrite is cool. But > > > > > > > the code may have been coming/inspired from OE ... in > > > > > > > which case it would not be cool, because it would fork > > > > > > > away further. > > > > > > > > > > > > > > > > > > OE uses a complete different implementation than to > > > > > > original: > > > > > > https://git.openembedded.org/openembedded-core/tree/meta/classes/useradd.bbclass > > > > > > > > > > > > see also: > > > > > > > > > > > > https://git.openembedded.org/openembedded-core/tree/meta-skeleton/recipes-skeleton/useradd/useradd-example.bb > > > > > > > > > > > > > > > > > > > > > > > > Quirin > > > > > > > > > > > > > > Henning > > > > > > > > > > > > > > > A rewrite of the image-account-extension in python was > > > > > > > > done on the way. This allows us to drop a lot of > > > > > > > > encoding and parsing code that was used to transition > > > > > > > > to shell and therefore made it easier to read and > > > > > > > > maintain. > > > > > > > > > > > > > > > > Using python functions for more complex tasks allows us > > > > > > > > the usage of unittests. A very basic infrastructure for > > > > > > > > unittesting using the build in python unittest and the > > > > > > > > bb.parse module was added. This was used to test the > > > > > > > > re-implementation of the image-account-extension as a > > > > > > > > first showcase. > > > > > > > > > > > > > > > > Tobias Schaffner (5): > > > > > > > > simplify image-account-extension > > > > > > > > allow creation of users/groups before rootfs > > > > > > > > creation create a minimal python unittest infrastructure > > > > > > > > add unittests for the image-account-extension > > > > > > > > set minimal python version in user_manual to 3.5 > > > > > > > > > > > > > > > > doc/user_manual.md | 4 > > > > > > > > +- meta/classes/image-account-extension.bbclass | 391 > > > > > > > > +++++++----------- testsuite/unittests/README.md > > > > > > > > > 28 ++ testsuite/unittests/bitbake.py | > > > > > > > > > 37 ++ > > > > > > > > testsuite/unittests/rootfs.py | 45 > > > > > > > > ++ .../unittests/test_image_account_extension.py | 175 > > > > > > > > ++++++++ 6 files changed, 434 insertions(+), 246 > > > > > > > > deletions(-) create mode 100644 > > > > > > > > testsuite/unittests/README.md create mode 100644 > > > > > > > > testsuite/unittests/bitbake.py create mode 100644 > > > > > > > > testsuite/unittests/rootfs.py create mode 100644 > > > > > > > > testsuite/unittests/test_image_account_extension.py > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >