>>>>> "Russ" == Russ Allbery <r...@debian.org> writes:
Russ> Sam Hartman <hartm...@debian.org> writes: >>>>>>> "Peter" == Peter Pentchev <r...@ringlet.net> writes: Peter> Hm, what happens if a sysadmin deliberately removed a file Peter> that the distribution ships in /etc, trying to make sure that Peter> some specific service could never possibly succeed if it Peter> should ever attempt PAM authentication? Then, if there is a Peter> default shipped in /usr, the service authentication attempts Peter> may suddenly start succeeding when the PAM packages are Peter> upgraded on an existing system. >> This might be an issue in general, but it is not an issue for >> PAM. PAM falls back on the other service if a service >> configuration cannot be found. Russ> I think that makes it an even more subtle problem, doesn't it? Russ> Currently, my understanding is that if I delete Russ> /etc/pam.d/lightdm, PAM falls back on /etc/pam.d/other. But Russ> if we define a search path for PAM configuration such that it Russ> first looks in /etc/pam.d and then in /usr/lib/pam.d, and I Russ> delete /etc/pam.d/lightdm, wouldn't PAM then fall back on Russ> /usr/lib/pam.d/lightdm and not /etc/pam.d/other? Unlike Russ> Peter's example, that would be a silent error; authentication Russ> may well succeed, but without running, say, pam_limits.so. Yes, thanks for pointing this out. --Sam