Hi!
On Wed, 2022-04-20 at 17:17:16 +0200, Vincent Lefevre wrote:
> Package: dpkg
> Version: 1.21.7
> Severity: normal
> 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.
- 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).
Changing the current behavior, without fsys metadata tracking assistance,
seems challenging, to say the least. This behavior has been like this
since the beginning of git history, which also means that the perhaps
more appropriate way to override these perms via statoverrides has never
worked on conffiles. So this is messy. :/
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).
- perhaps as a temporary workaround, delay the application of
statoverrides for a conffile until the conffile handling step, so that
we can better track the new conffile perms, but mostly for
reporting purposes only.
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.
This will mean we will be able to do a 3-way check (like we do with
contents using their digests) over the permissions, to decide when to
propagate the perms or not, in prompt or automatic mode, etc.
Thanks,
Guillem
