Bug 190159

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
condition.

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):
2.2.7-1
2.2.8-1
Possibly earlier relases, too...

How reproducible:
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)
  
Actual results:
It will repeatedly ask for your password, ignoring the passsword caching
timeout. You may also get a broken pipe error.

Expected results:
Sudo displays your allowed commands, and also caches your password. Depending on
how sudo is invoked, it should also run the user-specified command.

Additional info:
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.