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

[Henning Schild <henning.schild@siemens.com>]

Am Tue, 19 Jan 2021 10:08:25 +0100
schrieb Henning Schild <henning.schild@siemens.com>:

> 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%7Cde173c00-e982-4fda-8644-47edf4671d63%40ad011.siemens.com%7Cf108d28909264c483e3d08d8bc5646d1%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637466426022621736%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=nXdIXZTWYDOaDvvJkYCD1q1rYY2dsKuKPj0nUexZz5U%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.
> 
> 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.
> 
> > > 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.
> 
> > >
> > > 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.
> 
> 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.

Indeed, it does overwrite a modified copy ignoring config file
protection.

rm /etc/os-release 
cp /usr/lib/os-release /etc/os-release
vim /etc/os-release
apt-get install base-files --reinstall
ls -al /etc/os-release

It is also replaced when it is a symlink to another location.

Henning

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