This service will be undergoing maintenance at 03:30 UTC, 2016-05-27. It is expected to last about 2 hours
Bug 190159 - Agressive protection in pam_krb5 makes sudo fail (broken pipe)
Agressive protection in pam_krb5 makes sudo fail (broken pipe)
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: pam_krb5 (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
Brian Brock
:
Depends On:
Blocks: 213407
  Show dependency treegraph
 
Reported: 2006-04-28 07:03 EDT by Jon Fautley
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version: 2.2.9-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-09-12 11:42:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Tentative patch against 2.2.8 (1.21 KB, patch)
2006-04-28 07:03 EDT, Jon Fautley
no flags Details | Diff

  None (edit)
Description Jon Fautley 2006-04-28 07:03:47 EDT
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.
Comment 1 Jon Fautley 2006-04-28 07:03:48 EDT
Created attachment 128356 [details]
Tentative patch against 2.2.8

Note You need to log in before you can comment on or make changes to this bug.