Hi Chris,

thanks for adjusting the permission of /etc/ppp. Now with a lot less of
diagnostics on my end, I can narrow down remaining problems. We now move
to /etc/ppp/peers has having a directory metadtaa conflict. Again,
directory metadata depends on the unpack order.

The file /etc/ppp/peers is contained in the packages
 * ppp/2.5.2-1+2 as present in unstable
 * pppoe
   * 4.0-1 as present in trixie|forky|unstable
   * 4.0-1+b1 as present in trixie
   * 4.0-1+b2 as present in forky|unstable
 * wvdial
   * 1.61-8 as present in trixie
   * 1.61-8+b1 as present in trixie
   * 1.61-9 as present in forky|unstable
 * xtel
   * 3.3.0-30 as present in trixie
   * 3.3.0-32 as present in forky|unstable

This one affects way fewer packages and impacts me much less than the
earlier one. You mentioned your intentions to change the permission of
the peers directory as well, please take your time. In the mean time,
the existence of this bug report should make my tooling shut up. It also
makes you aware of what other packages ship /etc/ppp/peers.

Helmut

Hi Helmut, Guillem,

After discussing this with Helmut in Hamburg today, I have come up with
the following tentative plan to resolve this, which can be implemented
by changing only the ppp package.

My suggestion is this:

1. I'm going to do away with the use of the 'dip' group in ppp; at the
    end of this process /etc/ppp/peers/ will be root:root 0700 (as will
    /etc/chatscripts/) and /usr/sbin/pppd will be root:root 0755. This is
    partly to facilitate resolving this issue, and partly for security
    reasons (nobody actually runs pppd as an unprivileged user any more,
    and there are better ways to do this now anyway).

2. In the pppd tarball, I will let /etc/ppp/peers/ be mode 0755, just
    like it is in pppoe/wvdial/xtel. I believe that this should resolve
    the dpkg file metadata conflict.

3. I will add a dpkg-statoverride to the pppd maintainer scripts to set
    to mode on /etc/ppp/peers to root:root 0700.

For #3 I plan to follow the example of ssl-cert:

-
https://salsa.debian.org/apache-team/ssl-cert/-/blob/master/debian/postinst?ref_type=heads#L15-19
-
https://salsa.debian.org/apache-team/ssl-cert/-/blob/master/debian/postrm?ref_type=heads

I believe this is better than attempting to change the other affected
packages on multiple counts:

1. They are all old and 2 of the 3 only get minimal maintenance; one is
    orphaned. The packages are all over 20 years old and those files have
    "always been there".

2. The files in question are conffiles so we'd need to do the
    rm_conffile dance anyway if we were to move the files to
    /usr/share/doc.

Can you please confirm whether (a) this will indeed resolve the issue as
I think it will, and (b) are you happy for me to proceed with this plan?

Cheers,
Chris

Hi all,

I've implemented my plan in this Salsa MR, in case it's easier to see
the changes I propose to do than to read about them:

https://salsa.debian.org/debian/ppp/-/merge_requests/16

Cheers,
Chris

Hi!

Ah, this might also potentially make it possible to get rid of the
«Rules-Requires-Root: binary-targets» and rely on the default of «no».

Hmm, I think I'd rather see the actual intended perms be part of the
tar metadata. More so given that I think this is a security sensitive
directory?

For the dpkg metadata conflicts for directories, do not worry as much,
because this is not currently deployed, and we'll need a way to
designate either a package that "owns" a directory so that dpkg can
update the metadata when we want to change it in the package, or a way
to mark that a metadata update is intended (and semantics for transfer
of ownership, etc). Where for directories the only sane way I envision
this being handled would be at most a warning being emitted, otherwise
too much could end up breaking.

I think that regardless of my previous comment this could be fine,
mostly because this is a directory under /etc, where the admin might
have purposefully changed the dir permissions, and the way they would
need to change them would now be by checking the statoverrides. And we
do need to update the currently incorrect permissions anyway, where dpkg
will not do that for us even if the tarball contains the correct ones.

Given the packages update history and the amount involved, I think
trying to get them to be in sync with the intended metadata would be
more than reasonable. There should be enough time to handle this
during this release cycle. And even if dpkg deployed metadata tracking
right away, it should not be generating errors out of this anyway.

Hmm, I'm not sure I understand this concern, why would these files need
to be moved to /usr/share/doc if the permissions get changed? Isn't
the main problem only the directory?

If something would really require removing these conffiles, to me that
means that option would be less desirable as missing the conffiles by
default would be less user friendly.

Hopefully I've covered that. :)

Thanks, that was helpful.

Regards,
Guillem

Hi Chris and Guillem,

I was telling Chris much the same and as he preferred the statoverride
mechanism, I asked him to invite you for review.

I can probably shed some light here has much of the context happened
between me and Chris offline. We recognized that all of those conffiles
do not actually contain any configuration. Effectively, they're
documentation. Having the hermetic-/usr use case in mind, we considered
that moving them out of /etc below /usr would be a sensible path
forward.

I am aware that the hermetic-/usr view is not consensus. At present, it
is mainly Luca Boccassi pushing for it, but it vaguely makes sense to
me.

I hear you. We do have opposing views on this in Debian. Please let me
skip that discussion as I am fine either way and understand the
arguments of either side.

Helmut

Hi Guillem, Helmut,

So just for clarity on my part, what would the recommended way forwards
be for ppp? Make /etc/ppp/peers be 0700 in the tarball _and_ add the
statoverride as well? And at some point dpkg will figure out who "owns"
/etc/ppp/peers to resolve the metadata conflict?

Cheers,
Chris