Re: Do not plan to support /usr/lib/pam.d for Debian pam
On Fri, 15 Sept 2023 at 21:08, Sam Hartman <hartmans@debian.org> wrote:
>
>
>
> Apropos of the discussion about removing default configuration from
> /etc.
> 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
> basis.
> 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.
With the provision that I know next to nothing about pam - if I
understood correctly how it works, why not simply do both? Ship the
default file in the package under both /usr and /etc. Then, you get
the semantics you want with local changes tracking, and /etc wins over
the defaults. And we can have a working, bootable Debian container
with only /usr. As far as I've been told, pam is the only blocker
there - for a minimal image of course, but that's still quite a good
achievement. Wouldn't this work, or am I missing something?
Reply to: