[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: