Hi! On Wed, 2026-05-06 at 17:14:19 +0200, Chris Boot wrote: > On 06/05/2026 08:47, Helmut Grohne wrote: > > Package: ppp > > Version: 2.5.2-1+2 > > Severity: important > > User [email protected] > > Usertags: fsys-metadata-conflict > > Control: affects -1 + pppoe wvdial xtel
> > 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. > 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). 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». > 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. 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. > 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 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. > 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". 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. > 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. 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. > 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? Hopefully I've covered that. :) On Thu, 2026-05-07 at 14:07:34 +0200, Chris Boot wrote: > On 06/05/2026 17:14, Chris Boot wrote: > > 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. > > 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 Thanks, that was helpful. Regards, Guillem
