Red Hat Bugzilla – Bug 190159
Agressive protection in pam_krb5 makes sudo fail (broken pipe)
Last modified: 2007-11-30 17:11:31 EST
Description of problem:
pam_krb5 invokes /lib/security/pam_krb5/pam_krb5_storetmp and feeds it some data
via a pipe.
As a first action, pam_krb5_storetmp checks whether UID==EUID and GID==EGID and
exits otherwise. Therefore pam_krb5 library the gets a SIGPIPE when trying to
write to the pipe, apparently doesn't handle the signal correctly and takes the
whole invoking application (sudo in our case) down.
Running under a debugger or strace or running as a different (local) user
modifies behaviour sometimes to the point where pam_krb5_storetmp still fails
but the application survives, so we believe that we have something like a race
Our suggestion is to both check for the race (set up a handler for SIGPIPE), and
take out the UID==EUID check unless it is verified that "sudo" still works
correctly with it.
Version-Release number of selected component (if applicable):
Possibly earlier relases, too...
Because this is a probably race condition, it's not an easy one to reproduce.
It seems that if you slow down the sudo parent process enough, it should trigger
the bug. It can also happen without any manual intervention, but seemingly only
for certain user accounts.
Steps to Reproduce:
1. Configure a system to authenticate using pam_krb5afs
2. Attempt to run a sudo command (i.e. sudo -l)
It will repeatedly ask for your password, ignoring the passsword caching
timeout. You may also get a broken pipe error.
Sudo displays your allowed commands, and also caches your password. Depending on
how sudo is invoked, it should also run the user-specified command.
Tentative patch aginst 2.2.8 attached. One part fixes (hopefully) the UID!=EUID
that causes the problem, the other make ssure we get just an error message and
don't terminate the invoking process via SIGPIPE..
If you want to reproduce this, you may need to slow down the sudo parent process
(so that the helper executable has a chance to run/terminate before the parent
tries the "write()").
Thanks to Jan Iven at CERN for this patch/problem description.
Created attachment 128356 [details]
Tentative patch against 2.2.8