I am trying to setup sshd and pam_oath using /etc/liboath/users.oath as the configuration file. When attempting to login it prompts for the oath password, and then SELinux complains that it cannot create /etc/liboath/users.oath.lock Jan 01 09:25:47 localhost.localdomain python[4046]: SELinux is preventing sshd from create access on the file users.oath.lock. Changing context on the file doesn't help since it will go away when the login is done. A similar error happens on users.oath.new if you do run semanage on the .lock file. Login and oath work fine if SELinux is in Permissive mode. pam_oath-2.4.1-6.fc21.x86_64 selinux-policy-3.13.1-103.fc21.noarch selinux-policy-targeted-3.13.1-103.fc21.noarch ***** Plugin catchall_labels (83.8 confidence) suggests ******************* If you want to allow sshd to have create access on the users.oath.lock file Then you need to change the label on users.oath.lock Do # semanage fcontext -a -t FILE_TYPE 'users.oath.lock' where FILE_TYPE is one of the following: abrt_var_cache_t, auth_cache_t, auth_home_t, cgroup_t, faillog_t, gitosis_v Then execute: restorecon -v 'users.oath.lock' ***** Plugin catchall (17.1 confidence) suggests ************************** If you believe that sshd should be allowed create access on the users.oath.lock file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep sshd /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp
Why is pam_oath creating lock files in /etc/ rather then in /var/lock?
I was able to work around this manually by doing: semanage fcontext -a -t systemd_passwd_var_run_t '/etc/liboath(/.*)?' restorecon -rv /etc/liboath/
Yes that will work, but I would prefer to get this fixed for everone, by moving the lock file to the proper location.
(In reply to Daniel Walsh from comment #1) > Why is pam_oath creating lock files in /etc/ rather then in /var/lock? It's libaoath API, it allows using arbitrary file in the call as usersfile and locks it to prevent concurrent modifications. Multiple processes can use the API with arbitrary usersfile, thus it is not possible to use one lock file in /var/lock. Possible solutions: lock files based on hashes of path/name, or extension/modification of the API to support lock file location change. I am for the latter solution, but it would require modification of the liboath API, thus it needs to be approved by upstream. Also all projects using this API will require patches/recompilation. Thus in short term adding SELinux rule may be better solution.
I am also investigating possibility of removing the explicit lock files and using advisory locking of the usersfiles. This should work without API change. I will contact upstream about it.
(In reply to Jaroslav Škarvada from comment #5) > I am also investigating possibility of removing the explicit lock files and > using advisory locking of the usersfiles. This should work without API > change. I will contact upstream about it. Unfortunately it's not possible, it will introduce new race condition, focusing on solution from comment 4.
Created attachment 978182 [details] Proposed fix The attached patch is proof of concept that extends the liboath API (backward compatible way) and modifies the pam_oath module to use one global lock file /var/lock/pam_oath.lock. This should resolve the problem, upstream bug report including description of the proposed solution: https://savannah.nongnu.org/support/index.php?108723 Waiting for upstream, comments are welcome :)
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Moving this to rawhide so it doesn't get lost.
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle. Changing version to '24'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase
This still seem to be an issue with current CentOS 7 as well with the following package versions: $ rpm -qa | grep oath pam_oath-2.4.1-8.el7.x86_64 liboath-2.4.1-8.el7.x86_64 gen-oath-safe-0.10.0-1.el7.noarch
This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '24'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 24 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
This still needs attention. It's still a bug in Fedora and CentOS (EPEL)
Seeing this on EL7. Looks like it also updates the users.oath file: type=AVC msg=audit(1512420338.798:1227): avc: denied { create } for pid=8441 comm="sshd" name="users.oath.lock" scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:etc_t:s0 tclass=file type=AVC msg=audit(1512420338.798:1227): avc: denied { write } for pid=8441 comm="sshd" path="/etc/users.oath.lock" dev="sda2" ino=2851403 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:etc_t:s0 tclass=file type=AVC msg=audit(1512420338.820:1228): avc: denied { rename } for pid=8441 comm="sshd" name="users.oath.new" dev="sda2" ino=2851415 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:etc_t:s0 tclass=file type=AVC msg=audit(1512420338.820:1228): avc: denied { unlink } for pid=8441 comm="sshd" name="users.oath" dev="sda2" ino=2851397 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:etc_t:s0 tclass=file
This message is a reminder that Fedora 27 is nearing its end of life. On 2018-Nov-30 Fedora will stop maintaining and issuing updates for Fedora 27. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '27'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 27 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This bug appears to have been reported against 'rawhide' during the Fedora 30 development cycle. Changing version to '30.
This message is a reminder that Fedora 30 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '30'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 30 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Created attachment 1684746 [details] Proposed fix Patch rebased to the current version of oath-toolkit.
I used the patch in the rawhide and cloned the issue to the new upstream tracker: https://gitlab.com/oath-toolkit/oath-toolkit/-/issues/17
I will update/fix or revert it downstream according to the upstream reaction.