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
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