Re: Do not plan to support /usr/lib/pam.d for Debian pam
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.
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 (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: