Re: [isar-cip-core][RFC] Handling UIDs/GIDs on Updates

[Quirin Gylstorff <quirin.gylstorff@siemens.com>]

On 4/22/25 11:09, Jan Kiszka wrote:
> On 22.04.25 10:51, Heinisch, Alexander (FT RPD CED SES-AT) wrote:
>> Hi cip-dev community,
>>
>> Following RFC is not specific to isar-cip-core, but to the upgrade method we are using. So, maybe some of you are facing similar issues...
>>
>> The default update strategy updates the immutable partitions in an A/B scheme. Typically, the persistent data is kept as is (at least in the majority of use cases).
>> Some exceptions exist where minor changes (of small parts of /var) are supported by packages linking data from /var to the immutable partitions using tempfile.d aso.
>>
>> That leads to the following problem:
>>
>> Once we added users to the image with data on the persistent partition /var the UIDs/GIDs must remain consistent forever.
>> In case package order changes, or new user accounts get created in between, this could potentially results in a shift of those ids.
>> Since we only upgrade the immutable parts of the system data on /var remains with privileges for owners and groups as they were before the update.
>> Thus, resulting in a privilege mixup on /var after upgrades.
>>
>> To (partially) fix that problem multiple options exist:
>>

Debian developer rules on that topic
https://www.debian.org/doc/debian-policy/ch-opersys.html#introduction.

Here is the list of reserved uid/gids

https://salsa.debian.org/debian/base-passwd


>> 1. Define fixed UID/GID sets for our users.
>> While this helps with our own packages, it keeps the problem when using unmodified upstream packages not using static ids for uid and gid (e.g. wfx)
>>
Most uid/gid from Debian are generated by the alphabetic installation 
order so this will be the case if you change that order.

>> 2. Use tmpfile.d to modify ownerships on /var accordingly.
>> While this also fixes issues with upstream packages, it requires additional tooling / automation to keep it consistent with the ongoing image development.
>> e.g. ROOTFS_POSTPROCESS_COMMAND or similar.
>>
>> 3. Use a static predefined /etc/passwd file like in base-passwd.
>> Unfortunately, this does not scale very well, so we need to know all possible user accounts in advance.
>> And further, we have to ensure, that we never change UIDs GIDs (unintentionally) in that file as well.
>>
>> Any recommendations how to mitigate that issue?
>>
> 
> First quick thought: Can't we automate this, at least partly? After
> version 0 build of an image, extract the user&group lists with IDs and
> use that at base (like in option 3) for succeeding builds? If version 1
> adds another user, that would update the base list for version 2, and so on.
> 
 > Jan>

Quirin