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

Do not plan to support /usr/lib/pam.d for Debian pam

Apropos of the discussion about removing default configuration from
Upstream PAM now supports doing that.  You can set up a vendor directory
such as /usr/lib where pam.d and security live.

I thought about doing that for Debian PAM, and have decided against.
My rationale is that I actually think dpkg gives superior handling of
upstream configuration changes to what we'd get with the pam vendor dir
*in the specific case of PAM*.

In particular, dpkg will let you know if the conf file has changed
upstream and you have local changes.
If we create a vendor directory,  you will have to diff yourself to
discover that.

I do think that in the case of programs like systemd that do a complex
merge of drop in fragments, the split of vendor dir from sysadmin dir
makes a lot of sense.

But for the most part PAM appears to just override on a file-by-file
And for that use case, I think dpkg's handling is at least as good.
I appreciate others might differ.  With dpkg's conffile handling you get
better notification of changes but is it is hard to see at a glance
which files might be changed.

I am in favor of having a mechanism to easily reset the state in /etc.
Personally I'm not convinced that deleting /etc is the best way for
Debian to do that.
I think we might be able to find dpkg-based solutions that are superior.

If Debian  does develop a project consensus behind  minimizing
/etc--especially if there is a policy recommendation or encouragement in
this direction, then I'll revisit how we handle this for PAM.

If Debian develops another approach for resetting local state, I'll be
eager to look at that for PAM.


Attachment: signature.asc
Description: PGP signature

Reply to: