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. I think that makes it an even more subtle problem, doesn't it? Currently, my understanding is that if I delete /etc/pam.d/lightdm, PAM falls back on /etc/pam.d/other. But if we define a search path for PAM configuration such that it first looks in /etc/pam.d and then in /usr/lib/pam.d, and I delete /etc/pam.d/lightdm, wouldn't PAM then fall back on /usr/lib/pam.d/lightdm and not /etc/pam.d/other? Unlike Peter's example, that would be a silent error; authentication may well succeed, but without running, say, pam_limits.so. I don't know if anyone is making this specific configuration change, but if they are, I think that result would be surprising. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
