Re: Do not plan to support /usr/lib/pam.d for Debian pam
>>>>> "Russ" == Russ Allbery <rra@debian.org> writes:
Russ> Sam Hartman <hartmans@debian.org> writes:
>>>>>>> "Peter" == Peter Pentchev <roam@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
Reply to: