Re: image-postproc-extension.bbclass modifying /etc/os-release

[Silvano Cirujano Cuesta <silvano.cirujano-cuesta@siemens.com>]

I've tested it right now with the Qemu AMD64 image:

1. Modified it so that /etc/os-release has "my information".

2. Confirmed that /etc/os-release in the VM has "my information".

3. Made the current 'base-files' upstream package [1] available to the VM (additional disk, editing the generated image,...).

4. Installed the current 'base-files' upstream package.

5. Confirmed that "my" /etc/os-release has been silently replaced by a symlink to /usr/lib/os-release.

Anybody not doing package updates on 'base-files' won't notice anything, but the bug will still be there. Only covered by a convention, uncover it and it'll bite you...

Please convince me :-) that it's not a bug or that there are no realistic scenarios where it can be triggered... if not I'll contribute a fix.

  Silvano

[1] http://ftp.de.debian.org/debian/pool/main/b/base-files/base-files_10.3+deb10u7_amd64.deb

On 18/01/2021 13:35, Claudius Heine wrote:
> Hi Silvano,
>
> On 2021-01-18 12:35, Silvano Cirujano Cuesta wrote:
>> I might try to provide a fix, if we agree that the current implementation has an issue.
>>
>> @Claudius: you wrote the original code [1]. Do you remember why you implemented it this way? Do you remember if you were aware of the issue I mentioned and you provided a mitigation for the issue that I see (assuming my analysis is right)?
>>
>> [1] https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Filbers%2Fisar%2Fcommit%2F13ce96e5bc84b60f2fa7ccfe93dde045461884e6&data=04%7C01%7Csilvano.cirujano-cuesta%40siemens.com%7C0bf1a83dda684b9e03e408d8bbad9a58%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637465701582684886%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=rRq%2F%2BKNrHdUn1SV%2FxVTIOSH6BofosIhUrFZWyy5PmSc%3D&reserved=0
>>
>>    Silvano
>>
>> On 15/01/2021 15:26, [ext] Silvano Cirujano Cuesta wrote:
>>> Hi,
>>>
>>> I've noticed that '/etc/os-release' is being changed on the image in meta/classes/image-postproc-extension.bbclass [1].  What BTW ends up changing '/usr/lib/os-release', since it's only a symlink. But both '/etc/os-release' and '/usr/lib/os-release' are owned by 'base-files'...
>>>
>>> An upgrade of 'base-files' would be replacing (silently, since is not marked as a configuration file) '/usr/lib/os-release' with the version of the upstream 'base-files' package and possibly breaking any tools in the system relying on certain values in that file.
>>>
>>> Is there a reason that I'm missing for doing so instead of the Debian-way (file diversion with dpkg-divert)? Or any hack that I've overseen that avoids the mentioned breakage?
>
> Interesting, I didn't remember that `/etc/os-release` is a symlink, could that be something that has changed in more recent debian versions?
>
> If so then, of course that needs to be fixed.
>
> regards,
> Claudius