Bug 114453 - php-imap acquires and holds a read lock on /etc/krb5.keytab
php-imap acquires and holds a read lock on /etc/krb5.keytab
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: php (Show other bugs)
3.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Joe Orton
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-01-28 06:55 EST by John Haxby
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-19 15:30:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
strace output from httpd (911.26 KB, text/plain)
2004-01-29 08:32 EST, John Haxby
no flags Details

  None (edit)
Description John Haxby 2004-01-28 06:55:28 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030922

Description of problem:
With a Kerberos KDC installed, httpd acquires a read lock on
/etc/krb5.keytab which it does not release.   This happens when you
start httpd -- you don't have to make any HTTP queries at all (and
certainly nothing that requires any sort of authentication).  This
makes "kadmin 'ktadd <princ>'" hang trying to acquire an exclusive
lock on the keytab.

# lslk /etc/krb5.keytab
SRC    PID DEV    INUM  SZ TY M ST WH END LEN NAME
httpd 6071 3,6 1771009 462  r 0  0  0   0   0 /etc/krb5.keytab

# lsof /etc/krb5.keytab
COMMAND  PID   USER   FD   TYPE DEVICE SIZE    NODE NAME
httpd   6071   root   12rR  REG    3,6  462 1771009 /etc/krb5.keytab
httpd   6407 apache   12r   REG    3,6  462 1771009 /etc/krb5.keytab
httpd   6408 apache   12r   REG    3,6  462 1771009 /etc/krb5.keytab
httpd   6409 apache   12r   REG    3,6  462 1771009 /etc/krb5.keytab
httpd   6410 apache   12r   REG    3,6  462 1771009 /etc/krb5.keytab
httpd   6417 apache   12r   REG    3,6  462 1771009 /etc/krb5.keytab
httpd   6418 apache   12r   REG    3,6  462 1771009 /etc/krb5.keytab
httpd   6419 apache   12r   REG    3,6  462 1771009 /etc/krb5.keytab
httpd   6420 apache   12r   REG    3,6  462 1771009 /etc/krb5.keytab

I suspect, but I'm not sure that httpd is looking for a service key in
the keytab but it isn't finding it.   My keytab contains only entries
with the principal root "host", "ftp" and "imap".  I don't know what
root httpd wants though.



Version-Release number of selected component (if applicable):
httpd-2.0.46-26.ent

How reproducible:
Always

Steps to Reproduce:
1.  Configure a system as a kerberos client, make sure that there is
at least one principal in /etc/krb5.keytab (e.g. host/<hostname>@<realm>)
2. Start httpd
3. Run lslk, verify that httpd has a read lock on /etc/krb5.keytab
    

Actual Results:  See description showing lock.

Expected Results:  httpd should release it's lock on /etc/krb5.keytab
when it's finished with it.

Additional info:

It's possible to workaround this bug simply by shutting down httpd,
doing the ktadd thing and then starting httpd again.   Of course, this
is not blindingly obvious and is going to seriously confuse some people.
Comment 1 Joe Orton 2004-01-29 08:21:49 EST
Thanks for the report.  httpd does not use Kerberos directly: it must
be getting used indirectly, somehow.  After shutting down httpd, can
you run:

strace -o /tmp/httpd.trace -f /usr/sbin/httpd

as root, then attach the /tmp/httpd.trace produced?
Comment 2 John Haxby 2004-01-29 08:32:59 EST
Created attachment 97331 [details]
strace output from httpd

Here's the interesting bit where the lock is acquired.	 There are no more
references to descriptor 12 after this.   It's possibly interesting to note
module open before this lot is /usr/lib/php4/imap.so.

14226 close(12) 			= 0
14226 munmap(0x4110c000, 4096)		= 0
14226 stat64("/usr/kerberos/etc/krb5.conf", 0xbffff0c0) = -1 ENOENT (No such
file or directory)
14226 gettimeofday({1075382905, 148440}, NULL) = 0
14226 getpid()				= 14226
14226 stat64("/etc/krb5.conf", {st_mode=S_IFREG|0644, st_size=679, ...}) = 0
14226 stat64("/etc/krb5.conf", {st_mode=S_IFREG|0644, st_size=679, ...}) = 0
14226 stat64("/etc/krb5.conf", {st_mode=S_IFREG|0644, st_size=679, ...}) = 0
14226 stat64("/etc/krb5.conf", {st_mode=S_IFREG|0644, st_size=679, ...}) = 0
14226 stat64("/etc/krb5.conf", {st_mode=S_IFREG|0644, st_size=679, ...}) = 0
14226 stat64("/etc/krb5.conf", {st_mode=S_IFREG|0644, st_size=679, ...}) = 0
14226 stat64("/etc/krb5.conf", {st_mode=S_IFREG|0644, st_size=679, ...}) = 0
14226 stat64("/etc/krb5.conf", {st_mode=S_IFREG|0644, st_size=679, ...}) = 0
14226 open("/etc/krb5.keytab", O_RDONLY|O_LARGEFILE) = 12
14226 fcntl64(12, F_SETLKW64, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0},
0xbffff180) = 0
14226 read(12, "\5\2", 2)		= 2
14226 _llseek(12, 0, [2], SEEK_CUR)	= 0
14226 stat64("/dev/urandom", {st_mode=S_IFCHR|0644, st_rdev=makedev(1, 9),
...}) = 0
Comment 3 John Haxby 2004-01-29 08:37:42 EST
Further to my earlier comment.  The mysterious lock definitely happens
in php-imap-4.3.2-8.ent.   /etc/krb5.keytab is locked by httpd when  
 php-imap is installed and not otherwise.
Comment 4 Joe Orton 2004-01-29 08:40:40 EST
Great, thanks for narrowing this down.
Comment 5 RHEL Product and Program Management 2007-10-19 15:30:53 EDT
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
 
For more information of the RHEL errata support policy, please visit:
http://www.redhat.com/security/updates/errata/
 
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.

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