On Sat, 19 Dec 2020 03:02:47 -0800 Josh Triplett <[email protected]> wrote: > On Fri, 18 Dec 2020 08:54:42 -0500 Sam Hartman <[email protected]> wrote: > > >>>>> "Josh" == Josh Triplett <[email protected]> writes: > > Josh> I realize that this is an essential package, but it does have > > Josh> a prerm and postrm script, and on a system with absolutely no > > Josh> usage of PAM it should be posible to remove without > > Josh> encountering an infinite loop like this. > > > > I agree you shouldn't get the infinite loop. > > I'm not at all convinced that you should be able to remove the package. > > I think having the pam library installed without at least pam configs > > that are guaranteed to fail is more of a security risk than I'm > > comfortable with. > > You would not be the first person who was sure they were not using PAM > > only to discover that something under the covers was. > > You may well be correct in your instance. > > I've seen way too many people get this wrong over the years. > > Perhaps the PAM packages, when removed, could ensure that a minimal > "always deny everything" PAM configuration is in place, then? > > (As an aside, it seems surprising that libpam fails open rather than > failing closed. Would there be any way to fix that, without causing > backwards compatibility issues?)
Actually, I just tested this in a new chroot, and it looks like current PAM does correctly fail closed, with either no configuration or an empty configuration. With no /etc/pam.conf or /etc/pam.d, login will fail with "login: PAM Failure, aborting: Critical error - immediate abort". With an empty /etc/pam.conf and no /etc/pam.d, login will just always say "Login incorrect". Is there still a fail-open scenario here?
