Description of problem: pam_faillock needs cap_dac_override because it creates the /run/faillock/USER files with USER.root and mode 0600. pam_faillock then needs cap_dac_override to be able to write records to these files. Maybe mode 0660 is more appropriate? Version-Release number of selected component (if applicable): pam-1.3.1-15.fc30.x86_64 How reproducible: disallow cap_dac_override and see how pam_faillock breaks without any notice Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
On a slightly unrelated note: would it be possible to open these files for append only? Currently it opens it for write but is we can do with append only then we can use selinux to prevent erasing of records
Changing the mode to 0660 should work and it should probably still be safe, I'll need to think about it though. The files are not 'append only' the records are overwritten when successful login happens. So the comment 1 does not make sense.
Oh, right. I did not realize that records were being removed after success. I though only the faillock command would remove records. About the dac_override: I noticed this issue when i tried pam_faillock, my openssh-server does not have access to cap_dac_override and so pam_faillock did not work. I would prefer to not give daemons like openssh-server dac_override capability unless strictly necessary.
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to '31'.
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to 31.
This bug appears to have been reported against 'rawhide' during the Fedora 32 development cycle. Changing version to 32.
I've fixed the problem by changing the permissions of the file to 0660, so nowadays you shouldn't have any problem. Can you test it? I've done a build for Fedora 32: https://koji.fedoraproject.org/koji/taskinfo?taskID=45597282
This fixes it for me (sshd no longer needs cap_dac_override just for pam_faillock)
Thank you for the test!
* master 395915dae1571e10e2766c999974de864655ea3a - pam_faillock: change /run/faillock/$USER permissions to 0660
FEDORA-2020-de9a616c38 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-de9a616c38
FEDORA-2020-de9a616c38 has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-de9a616c38` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-de9a616c38 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-de9a616c38 has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-025ab83d69 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-025ab83d69
FEDORA-2020-025ab83d69 has been pushed to the Fedora 31 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-025ab83d69` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-025ab83d69 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-025ab83d69 has been pushed to the Fedora 31 stable repository. If problem still persists, please make note of it in this bug report.