> I don't think moving parts of the user configuration out of the config files is acceptable, and if you disable and then re-enable a module, I don't see any reason that the config options *should* be sticky.
I wasn't so much proposing an alternative, just going over the shortcomings I see of this approach. (Sticky options would present another quandary---what if they're wrong, and you're not sure how? What easy way do you have to revert to a "pristine" config, if disabling/re- enabling a module doesn't do it?) > pam-auth-update already implements the usual guarantee required by Debian/Ubuntu policy - that local configuration changes are respected. Helping the user understand which bits of the configuration *are* local changes is gravy. What's implemented now is serviceable, to be sure, but I think the PAM config warrants a higher level of transparency than (say) inetd.conf. Maybe it can be machine-generated comments in the common-* files that indicate which options are customized; maybe some external file (/etc/pam.overrides? pam.custom?) that stores these options, allowing easy review and editing. I don't know what the solution would be---only that I'm vaguely uncomfortable with something as critical as the PAM config having this not-easily-inspected space in which changes can be made. There's definitely room for improvement here. -- Why is /usr/share/pam-configs/krb5 specifying minimum_uid= ? https://bugs.launchpad.net/bugs/369575 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to kerberos-configs in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
