Bug#1135816: ppp has a directory metadata conflict on /etc/ppp/peers
Hi Guillem, Helmut, On 11/05/2026 10:32, Helmut Grohne wrote: Hi Chris and Guillem, On Sun, May 10, 2026 at 08:28:25PM +0200, Guillem Jover wrote: On Wed, 2026-05-06 at 17:14:19 +0200, Chris Boot wrote: 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? I was telling Chris much the same and as he preferred the statoverride mechanism, I asked him to invite you for review. 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 -- Chris Boot [email protected]
Bug#1135816: ppp has a directory metadata conflict on /etc/ppp/peers
Hi Chris and Guillem, On Sun, May 10, 2026 at 08:28:25PM +0200, Guillem Jover wrote: > On Wed, 2026-05-06 at 17:14:19 +0200, Chris Boot wrote: > > 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? I was telling Chris much the same and as he preferred the statoverride mechanism, I asked him to invite you for review. > > 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? 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. > 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. 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
Bug#1135816: ppp has a directory metadata conflict on /etc/ppp/peers
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. > C
Bug#1135816: ppp has a directory metadata conflict on /etc/ppp/peers
Hi all, 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 Cheers, Chris -- Chris Boot [email protected]
Bug#1135816: ppp has a directory metadata conflict on /etc/ppp/peers
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 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. 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 -- Chris Boot [email protected]
Bug#1135816: ppp has a directory metadata conflict on /etc/ppp/peers
Package: ppp Version: 2.5.2-1+2 Severity: important User [email protected] Usertags: fsys-metadata-conflict Control: affects -1 + pppoe wvdial xtel 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
