On Fri, Sep 15, 2023 at 09:53:24PM +0100, Luca Boccassi wrote: > On Fri, 15 Sept 2023 at 21:08, Sam Hartman <hartm...@debian.org> wrote: > > > > > > > > Apropos of the discussion about removing default configuration from > > /etc. > > Upstream PAM now supports doing that. You can set up a vendor directory > > such as /usr/lib where pam.d and security live. > > > > I thought about doing that for Debian PAM, and have decided against. > > My rationale is that I actually think dpkg gives superior handling of > > upstream configuration changes to what we'd get with the pam vendor dir > > *in the specific case of PAM*. > > > > In particular, dpkg will let you know if the conf file has changed > > upstream and you have local changes. > > If we create a vendor directory, you will have to diff yourself to > > discover that. > > > > I do think that in the case of programs like systemd that do a complex > > merge of drop in fragments, the split of vendor dir from sysadmin dir > > makes a lot of sense. > > > > But for the most part PAM appears to just override on a file-by-file > > basis. > > And for that use case, I think dpkg's handling is at least as good. > > I appreciate others might differ. With dpkg's conffile handling you get > > better notification of changes but is it is hard to see at a glance > > which files might be changed. > > > > I am in favor of having a mechanism to easily reset the state in /etc. > > Personally I'm not convinced that deleting /etc is the best way for > > Debian to do that. > > I think we might be able to find dpkg-based solutions that are superior. > > > > If Debian does develop a project consensus behind minimizing > > /etc--especially if there is a policy recommendation or encouragement in > > this direction, then I'll revisit how we handle this for PAM. > > > > If Debian develops another approach for resetting local state, I'll be > > eager to look at that for PAM. > > With the provision that I know next to nothing about pam - if I > understood correctly how it works, why not simply do both? Ship the > default file in the package under both /usr and /etc. Then, you get > the semantics you want with local changes tracking, and /etc wins over > the defaults. And we can have a working, bootable Debian container > with only /usr. As far as I've been told, pam is the only blocker > there - for a minimal image of course, but that's still quite a good > achievement. Wouldn't this work, or am I missing something?
Hm, what happens if a sysadmin deliberately removed a file that the distribution ships in /etc, trying to make sure that some specific service could never possibly succeed if it should ever attempt PAM authentication? Then, if there is a default shipped in /usr, the service authentication attempts may suddenly start succeeding when the PAM packages are upgraded on an existing system. Yes, I know that the override/drop-in mechanism provides a way to do that by creating a /dev/null override symlink, but the sysadmin would not have needed to do that - until now, when they suddenly do. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
signature.asc
Description: PGP signature
