passswd doesn't work with yppasswd running on the same machine. passwd holds the lock on /etc/.pwd.lock while calling yppasswd which will try to get the same lock. It winds up with # passwd Changing password for user union. Changing password for union (current) UNIX password: New password: Retype new password: RPC: Timed out The password has not been changed on gate.in.lucon.org. passwd: Failed preliminary check by password service In messages: Sep 13 21:12:53 gate passwd(pam_unix)[11166]: password not changed for union on gate.in.lucon.org Sep 13 21:12:53 gate rpc.yppasswdd[10712]: update union (uid=10003) from host 192.168.0.6 successful. Sep 13 21:12:53 gate rpc.yppasswdd[10712]: update union (uid=10003) from host 192.168.0.6 rejected Sep 13 21:12:53 gate rpc.yppasswdd[10712]: Invalid password. Sep 13 21:12:53 gate rpc.yppasswdd[10712]: update union (uid=10003) from host 192.168.0.6 rejected Sep 13 21:12:53 gate rpc.yppasswdd[10712]: Invalid password. Sep 13 21:12:53 gate rpc.yppasswdd[10712]: update union (uid=10003) from host 192.168.0.6 rejected
The bug is in pam. I am uploading a patch.
Created attachment 76164 [details] A patch to avoid the deadlock with NIS
Created attachment 76165 [details] Oops. Ignore the last one. This is the right one.
Has this been applied?
This is also present in 8.0. If I turn off ypbind on the server it will work, but a have to call make manually in /var/yp to update the nis information.
This issue is still present in Red Hat 9. Applying the patch listed above solves the problem for me...shouldn't this find its way into the errata for 9?
Issue is still present in Fedora Core 1, and it doesn't look like a relevant patch has been added in Core 2. The above patch doesn't apply cleanly, but it doesn't look too far off...I'll see what I can do with it.
This behavior is reportedly fixed upstream in 0.78, which also addresses the obvious DoS inherent in this bug. http://sourceforge.net/tracker/?group_id=6663&atid=106663&func=detail&aid=664290 I have created a patch that applies cleanly to the 0.77-15 SRPM, which I'll attach. It isn't thoroughly tested as I just installed it ten minutes ago, but pam works correctly for me for the first time in months (I had patched the RH9 version which was in service until then). I would love for this fix to get into an FC1 and FC2 errata, and RHEL for that matter, which also exhibited the problem last time I checked. If there's anything I can do beyond providing a patch to encourage an errata for this problem, please let me know. Did I mention that it is a known user-exploitable DoS?
Created attachment 105176 [details] Patch to fix locking DoS in pam-0.77 Applies cleanly to the latest FC1 errata pam package. Mostly untested, but it works for me.
I'm sorry but the patch completely removes the locking which is not right. I'll try to resolve it correctly.
OK, the patch is more intrusive than I noticed, though it doesn't /completely/ remove locking, there's still the first one at line ~610. ;-) All of the individual locks might be able to come back without breaking anything--the earlier patch only modified one set of locks and it resolved the problem for earlier pam versions. I'll poke at it some more, though I'm well out of my depth on this one.
Ok, I've taken the previous patch, slightly changed it and applied.