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

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

[Heinisch, Alexander]

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:

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)

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?

BR Alexander

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

[Jan Kiszka]

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:
> 
> 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)
> 
> 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

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

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

[Quirin Gylstorff]

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