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

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

On 19/01/2021 10:08, Henning Schild wrote:
> Am Tue, 19 Jan 2021 09:43:17 +0100
> schrieb Silvano Cirujano Cuesta <silvano.cirujano-cuesta@siemens.com>:
>
>> On 19/01/2021 09:25, Henning Schild wrote:
>>> Am Mon, 18 Jan 2021 13:35:53 +0100
>>> schrieb Claudius Heine <ch@denx.de>:
>>>  
>>>> 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&amp;data=04%7C01%7Csilvano.cirujano-cuesta%40siemens.com%7C2b01ef368ee24a52b9b908d8bc59c9b3%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637466441106647009%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=CN8sFDPYqhNRf%2BeDzmc%2Fz%2FOOXunMg6cP4%2FmgEBa%2Bbr4%3D&amp;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.  
>>> the problem seems to be that it is a symlink, otherwise one would
>>> assume that changes in /etc/ are allowed and covered by the config
>>> file exception and will be subject to merging if an updated package
>>> comes around.  
>> No, that's wrong. The issue is not that it's a symlink, the issue is
>> that it's a package-managed file that hasn't been declared as a
>> configuration file.
>>
>> I agree with you that files under /etc should be changeable, but...
>> Debian found sort of a compromise between using the standard path
>> /etc/os-release and not expecting it to be changed (symlink to
>> /usr/lib and no configuration). You can like it or not, but that's
>> what we have to live with...
> We should not follow that symlink, but i would still hope that we are
> allowed to recreate that file without the risk of that package
> overwriting the file in /etc/ if it became a file and is modified.

I was expecting dpkg to report the problem, but I decided to test it before reporting this issue to have as much knowledge about the situation as possible.

What happens is that an update of "base-files" silently restores the symlink to /usr/lib/os-release, removing whatever is there.

>
> Problem with the copy is that a major update would not be reflected.
> Say your isar image starts off with debian9, a dist-upgrade might leave
> you with 9 in there.
Sorry, I don't get what you mean.
>
>>> My guess would be that we need to
>>>  - make it a copy instead of a symlink
>>>  - modify it  
>> As long as the file remains managed by "base-files", none of this
>> should be done. Either we replace "base-files" or we create file
>> diversions for those files. I wanted to focus this thread on
>> confirming the issue, I've opened another thread to align on how to
>> fix this issue. My proposal there is to contact the Debian
>> Derivatives mailing list.
> Dont know what a file diversion is, but also sounds like a hack that
> would not cover the dist-upgrade correctly.

That's exactly the opposite, it's the Debian way to support that a package can manage a file that was being managed previously by another one. And making all these modifications manageable by dpkg, even restoring the original files is supported.

"dpkg-divert --list" gives you all the file diversions you have on a Debian system. Packages doing diversions are "dash", "firefox-esr", "vim-runtime",...

See here: https://wiki.debian.org/DpkgDiversions

>
>>> In this case an update of the base-files package should leave it
>>> alone or ask for a merge. And i think that would be OK behaviour.  
>> But that's not the case if updating upstream Debian "base-files", it
>> silently replaces whatever we place there (file or symlink) with a
>> symlink to /usr/lib/os-release.
> Are you sure about that? That would have to be an "ln -sf" in a
> postinst or something, maybe you can share a link to the code doing
> that.
I've tested it myself. Built an ISAR qemu-amd64 image, uploaded upstream "base-files", installed it and gone it was (silently, not nice). No more ISAR /etc/os-release.
>
> If there is code that overwrites a file in /etc without config file
> protection, that would clearly be a reason to start talking to
> upstream. Because it would be a violation of how config files work in
> general.

You might be right. I agree with Debian on considering that OS information is not configuration. But they probably didn't want to divert from the Linux common path /etc/os-release.

Considering the content of /usr/lib/os-release something that shouldn't be changeable, they had to break one of following too Linux consents:

- files in /etc are configurations and changeable

- OS information is available under /etc/os-release

  Silvano

>
> Henning
>
>>   Silvano
>>
>>> Henning
>>>  
>>>> regards,
>>>> Claudius
>>>>  

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux