Comment # 74 on bug 1081947 from Stanislav Brabec

Thorsten Kukuk: So what solutions your propose?

If we use noreplace, that we will get bug reports like "pam_keyinit not
integrated after upgrade" or "last login shown twice" (bug 1082293).

I can imagine:

a) Remove "noreplace". Allow PAM file change only for new products or service
packs. Prohibit any packaged PAM file changes in online updates, so online
update will never overwrite PAM file, but new product release or migration can
do it. (Easy to do, but my recent online update has to be redone.)

b) Keep "noreplace" and risk side-effects of outdated PAM files (e. g. bug
1082293 will be closed as RESOLVED INVALID). Maybe report the existing backup
to the console. (Easy to do it.)

c) Keep "noreplace" and track all PAM file changes back to the beginning of the
"noreplace" history, and provide a special migration %post that makes required.
(Complicated, as it requires digging into old releases.)

Example:
if grep "^auth.*default=bad.*pam_securetty\\.so" /etc/pam.d/login ; then
    sed -i "/^auth.*default=bad.*pam_securetty\\.so/d" /etc/pam.d/login
fi
if ! grep "^session.*pam_keyinit\\.so" /etc/pam.d/login ; then
    echo "session  optional       pam_keyinit.so force revoke"
>>/etc/pam.d/login
fi
etc.


d) Invent a special check/tool that can track pam file changes.

I was working on a check that will trigger build failure whenever PAM file is
changed and migration script is not made. I can finish it and make a RPM macro
for that.

(Also complicated, as it requires digging into old releases, but once it will
be done, it will be safe for future.)