[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

On Fri, Sep 15, 2023 at 09:53:24PM +0100, Luca Boccassi wrote:
> 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?

Hm, what happens if a sysadmin deliberately removed a file that
the distribution ships in /etc, trying to make sure that some specific
service could never possibly succeed if it should ever attempt
PAM authentication? Then, if there is a default shipped in /usr,
the service authentication attempts may suddenly start succeeding
when the PAM packages are upgraded on an existing system.

Yes, I know that the override/drop-in mechanism provides a way to
do that by creating a /dev/null override symlink, but the sysadmin
would not have needed to do that - until now, when they suddenly do.


Peter Pentchev  roam@ringlet.net roam@debian.org pp@storpool.com
PGP key:        http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13

Attachment: signature.asc
Description: PGP signature

Reply to: