Replace subprocess grep calls with bash substring matching in
check_nosuid_whitelist function. This eliminates ~10k unneeded
subprocess spawns that were causing significant performance
degradation.
In testing, it improves overall script execution speed by an
order of magnitude:
Before patch:
$ sudo hyperfine -- './permission-hardener enable'
Benchmark 1: ./permission-hardener enable
Time (mean ± σ): 11.906 s ± 0.974 s [User: 3.639 s, System: 8.728 s]
Range (min … max): 10.430 s … 14.090 s 10 runs
After patch:
$ sudo hyperfine -- './permission-hardener enable'
Benchmark 1: ./permission-hardener enable
Time (mean ± σ): 802.8 ms ± 178.5 ms [User: 283.0 ms, System: 471.9 ms]
Range (min … max): 639.4 ms … 1092.3 ms 10 runs
For root, faillock appears to always* return an empty string (i.e. no table headers are present), yielding a zero-initialized pam_faillock_output_count and thus resulting in the calculation of a negative failed_login_counter value.
This can cause erroneous errors of the form "ERROR: Login blocked after [negative number] attempts" during sudo-ing and screen unlocking.
This commit modifies the initialization of failed_login_counter such that it cannot be negative and prevents the display of these incorrect warnings.
* Only rudimentary local tests were conducted
For root, faillock appears to always* return an empty string (i.e. no table headers are present), yielding a zero-initialized pam_faillock_output_count and thus resulting in the calculation of a negative failed_login_counter value.
This can cause erroneous errors of the form "ERROR: Login blocked after [negative number] attempts" during sudo-ing and screen unlocking.
This commit modifies the initialization of failed_login_counter such that it cannot be negative and prevents the display of these incorrect warnings.
* Only rudimentary tests were conducted
