[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

>>>>> "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.


Reply to: