Hi Guillem, On 2022-04-23 19:22:37 +0200, Guillem Jover wrote: > On Wed, 2022-04-20 at 17:17:16 +0200, Vincent Lefevre wrote: > > In an upgrade, the user may get a prompt like that and answer yes > > to install the package maintainer's version of a conffile, thus > > reverting all changes done he had done: > > > > Configuration file '/etc/resolvconf/update.d/unbound' > > ==> Modified (by you or by a script) since installation. > > ==> Package distributor has shipped an updated version. > > What would you like to do about it ? Your options are: > > Y or I : install the package maintainer's version > > N or O : keep your currently-installed version > > D : show the differences between the versions > > Z : start a shell to examine the situation > > The default action is to keep your current version. > > *** unbound (Y/I/N/O/D/Z) [default=N] ? Y > > Installing new version of config file /etc/resolvconf/update.d/unbound ... > > [...] > > > > However, if the user had changed the execute permission, e.g. to > > enable the script after modifying it, the execute permission is > > not restored to the default one. > > > > The execute permission is part of the file, thus should be propagated > > like the contents. > > Right, ideally yes. > > > The current behavior is an issue since a script may be disabled > > by default because it could be incorrect until the user has > > adapted it for his own usage. And the message like > > > > Installing new version of config file /etc/resolvconf/update.d/unbound ... > > > > (letting the user think that the conffile is reverted to the default, > > without informing him that the execute bit is not copied) is > > misleading. > > > > An alternative solution would be a 5th option, splitting the > > > > Y or I : install the package maintainer's version > > > > choice, when there is a difference for the execute permission. > > There are currently three main problems that make substantial immediate > improvements to this rather impractical. :/ > > - There is no tracking (yet) of fsys metadata, so dpkg does not know > what were the original old conffile perms, and thus cannot take > them into account as part of a "modified" check, otherwise we would > end up prompting unnecessarily when the perms are different between > the installed old and stock new conffiles.
Tracking would be fine in some cases; however, note that in the context of my bug report, this would be unnecessary: there is already a change in the contents, i.e. dpkg already prompts. The idea is: since the user wants to revert his changes on the contents, then it also makes sense to revert his change on the permissions too. > - The statoverrides are applied on unpack, so right now we even lose > the minimal tracking we could have over the new conffile shipped in > the .deb. > - The perms are unconditionally copied from the current to the new > conffile, and given the current constraints, stopping doing that > could have either small (perms) data loss consequences, or could > have security implications (even for the install-new-conffile case, > as a common way people resolve new changes might be to spawn a shell > during the prompt and incorporate the old modifications into the new > file). Do you mean that when dpkg unpacks the package, it copies the perms from the user's current conffile to the distributed version, and they look if there is any difference? This is rather complicated and is even a lie if the user chooses to keep his version (the .dpkg-dist file would have the user's perms instead of the perms from the package). > Changing the current behavior, without fsys metadata tracking > assistance, seems challenging, to say the least. But no tracking is necessary: the context is that one gets the prompt due to the changes in the contents; then it is the user's decision to replace his current conffile by the distributed one, and this should be done entirely, i.e. including the perms. > I think right now what I could do, that I think is safe and meaningful > would be to: > > - document that currently (but that would change) statoverrides for > conffiles does not have a practical effect. > - show the permission differences during the prompt (current, new, > whether there is any ineffective override in place). If it can show a difference during the prompt, then the permissions could be propagated. So I'm confused. > Ideally in the future once we have fsys metadata tracking: > > - stop unconditionally copying the old perms into the new conffiles. > - take permissions into account as part of the "modified" check, > and show and apply any meaningful permission change there, taking > statoverrides into account. While taking permissions into account as part of the "modified" check would be fine, this is not what I'm asking here. -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
