I had to use jump directives with pam_tally2, prior to my knowledge of faillock to meet requirements. As for impossible configuration - I'm happy with RHEL's, which is probably the most tricky part... it does suffer from redundant args, at least they are within a line of eachother though. auth required pam_faillock.so preauth silent audit deny=3 unlock_time=600 auth sufficient pam_unix.so nullok try_first_pass auth [default=die] pam_faillock.so authfail audit deny=3 unlock_time=600 pam-config was useless in the advanced configurations I had to apply. For screensaver handling - from the pam_faillock manpage: The individual files with the failure records are created as owned by the user. This allows pam_faillock.so module to work correctly when it is called from a screensaver I do not see (maybe it is my failure) cases where pam_faillock and screensavers work correctly - only issues/mails where it is broken. Further, even if you don't think this should be upstream... and playing devils advocate here, you may still have problems meeting approved security configurations with only pam_tally2 - this has an effect on the usage of any SUSE product in government owned systems. -Jason On Fri, Jun 3, 2016 at 4:45 AM, Thorsten Kukuk <kukuk@suse.de> wrote:
On Thu, Jun 02, Jason Newton wrote:
I'd consider adding it as an update, too, to 42.1 and SP1, at least in aux repositories - preferably to updates :-).
I've spoken with the author of pam_faillock and I believe it to be superior to pam_tally2, particularly concerning handling of screensaver handling.
There is one very good reason, why the upstream PAM maintainer rejected to include this module: it is next to impossible to configure it correct. Did you look at the example, how to configure a service to use this module? The module has one big design disadvantage: it needs to be called several time in a PAM stack, and you need jump directives, depending on the result of a module. While this works with only pam_unix.so, it will be next to impossible to some more complex authentication stacks. So tools like pam-config will never support pam_faillock. The whole mess could be avoided, if pam_faillock would have not be designed under the assumption, that all PAM applications by design are broken ...
Beside I fail to see your problem with screensaver handling. pam_faillock and pam_tally2 needs both the same rights.
Thorsten
-- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org