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.

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.

Hi!

Right, ideally yes.

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

Hi Guillem,
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.

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).
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.

If it can show a difference during the prompt, then the permissions
could be propagated. So I'm confused.

While taking permissions into account as part of the "modified" check
would be fine, this is not what I'm asking here.

Es gibt eine Familienspende in Höhe von 1.850.000,00 USD von Cheng Charlie
Saephan. Bitte antworten Sie für weitere Informationen. Denken Sie daran,
Ihrer Familie und den Bedürftigen in Ihrer Umgebung Gutes zu tun.

Dies ist bereits der zweite Versuch, Sie zu erreichen. Bitte antworten Sie
für weitere Details.