It sounds like you're assuming that someone will add pam_tally or
pam_pam_tally2 using a package profile in /usr/share/pam-configs.
I was assuming someone would add pam_tally or pam_tally2 by modifying
the config in /etc/pam.d directly.
Yes, I was assuming this. after I discovered pam-auth-config this seemed
like the best way to manage this stuff, even manually. Additionally I am
involved in a project, which handles hardening of server configurations.
There we also use this approach:
https://github.com/dev-sec/ansible-collection-hardening/blob/master/roles/os_hardening/templates/usr/share/pam-configs/pam_tally2.j2
First, I'm guessing that when you talk about someone enabling pam_tally
through pam-configs you are talking about in a profile they wrote,
not
in a package in Debian.
If there's a package in Debian that enables pam_tally we should file a
bug against that package and use a breaks relationship to avoid the
issue.
Yes I was assuming, that users als use pam-config. As for packages, I am
currently not aware of any package in Debian, that does this. But as
stated above, there are automation solutions, that use this approach.
If someone has included a module they wrote in /usr/share/pam-configs,
I
agree with your original approach: we should detect that module and
halt
the upgrade.
I only partially agree with this. Disabling the detected pam-config is
one of the most clear and safe things we could do automatically. but we
should definately tell the user, that we have detected an incompatible
config nad disabled it.
However, if there are no modules that enable pam_tally from pam-configs
but there are entries in /etc/pam.d/* think we should comment
those entries out.
This is where I disagree. We can not in any automatic way decide how we
handle the configs in /etc/pam.d. In any case we should produce a diff
an let the user sort things out.
I am thinking of using ufc in a way like this:
https://salsa.debian.org/ssh-team/openssh/-/blob/master/debian/openssh-server.postinst#L83
So, why do I disagree. Consider a user wanting to use tally, but only
for users with uid > 1000. This would be possible with this pam config:
auth [default=1 ignore=ignore success=ok] pam_succeed_if.so uid
>= 1000 quiet
auth required pam_tally2.so
auth sufficient pam_unix.so nullok try_first_pass
If we disable tally by commenting/deleting the one line, we would
instruct pam to skip pam_unix.so for every user, who has a uid > 1000.
This is a problem, only if we are directly meddling in /etc/pam.d for
pam-config profiles this should be handled by the updte script. Unless
the user has done something teirselves to /etc/pam.d. Which leeds us
to the above statement agein. Once we start editing /etc/pam.d without
respectiong the context of all pam modules things get messy.
