Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.427 (Entity 5.427) X-RT-Original-Encoding: iso-8859-1 Content-Length: 16831 From krb5-bugs-incoming-bounces@PCH.mit.edu Wed Mar 9 14:56:33 2011 Return-Path: Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by krbdev.mit.edu (Postfix) with ESMTP id 854D03DC65; Wed, 9 Mar 2011 14:56:33 -0500 (EST) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id p29JuXtS028870; Wed, 9 Mar 2011 14:56:33 -0500 Received: from mailhub-dmz-1.mit.edu (MAILHUB-DMZ-1.MIT.EDU [18.9.21.41]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id p29JkrTe027394 for ; Wed, 9 Mar 2011 14:46:54 -0500 Received: from dmz-mailsec-scanner-4.mit.edu (DMZ-MAILSEC-SCANNER-4.MIT.EDU [18.9.25.15]) by mailhub-dmz-1.mit.edu (8.13.8/8.9.2) with ESMTP id p29Jjjg5021262 for ; Wed, 9 Mar 2011 14:46:53 -0500 X-AuditID: 1209190f-b7c1dae000000a2b-87-4d77d92c7831 Received: from sjciron01.datadomain.com ( [208.84.140.10]) by dmz-mailsec-scanner-4.mit.edu (Symantec Brightmail Gateway) with SMTP id 51.2A.02603.C29D77D4; Wed, 9 Mar 2011 14:46:53 -0500 (EST) X-IronPort-AV: E=Sophos;i="4.62,291,1297065600"; d="scan'208,217";a="32977342" Received: from unknown (HELO SJCEXFE01.DataDomain.com) ([172.16.13.1]) by sjciron01.datadomain.com with ESMTP/TLS/RC4-MD5; 09 Mar 2011 11:46:52 -0800 Received: from SJCEXBE02.DataDomain.com ([10.24.17.52]) by SJCEXFE01.DataDomain.com ([10.24.17.61]) with mapi; Wed, 9 Mar 2011 11:46:51 -0800 From: Jim Uren To: "krb5-bugs@mit.edu" Date: Wed, 9 Mar 2011 11:46:51 -0800 Subject: bug report: 1Gb krb5.keytab file generated Thread-Topic: bug report: 1Gb krb5.keytab file generated Thread-Index: AcvekrvzvEWDLjnRQcmUbBSCsEA0sg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C38669469756764EA77F5B406CE9AC7E326B812Fsjcexbe02DataDo_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Wed, 09 Mar 2011 14:56:32 -0500 Cc: Jim Uren X-BeenThere: krb5-bugs-incoming@mailman.mit.edu X-Mailman-Version: 2.1.6 Precedence: list Sender: krb5-bugs-incoming-bounces@PCH.mit.edu Errors-To: krb5-bugs-incoming-bounces@PCH.mit.edu --_000_C38669469756764EA77F5B406CE9AC7E326B812Fsjcexbe02DataDo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable SEND-PR: -*- send-pr -*- SEND-PR: Lines starting with `SEND-PR' will be removed automatically, as SEND-PR: will all comments (text enclosed in `<' and `>'). SEND-PR: SEND-PR: Please consult the send-pr man page `send-pr(1)' or the Texinfo SEND-PR: manual if you are not sure how to fill out a problem report. SEND-PR: SEND-PR: Choose from the following categories: SEND-PR: SEND-PR: krb5-admin krb5-appl krb5-build krb5-clients SEND-PR: krb5-doc krb5-kdc krb5-libs krb5-misc SEND-PR: pty telnet test SEND-PR: To: krb5-bugs@mit.edu Subject: /etc/krb5.keytab is 1Gb in size From: sysadmin Reply-To: sysadmin Cc: X-send-pr-version: 3.99 >Submitter-Id: net >Originator: Jim.Uren@EMC.com >Organization: EMC Corporation >Confidential: no >Synopsis: Keytab file grows to 1Gb in size >Severity: serious >Priority: medium >Category: krb5-libs >Class: sw-bug >Release: 1.4.1 >Environment: System: Linux ccm2.chaos.local 2.6.23-ddr233377 #1 SMP Tue Mar 1 11:05:31 P= ST 2011 x86_64 x86_64 x86_64 GNU/Linux Architecture: x86_64 >Description: Our product uses a CIFS server provided by Likewise.com, which in t= urns ships its code with Kerberos. We have seen a problem in which a huge /etc/krb5.keytab file is gen= erated. This seems to be due to non-robust error handling. The problem occurs when the current keytab file is truncated, and t= he code generates a new keytab file. >How-To-Repeat: We are able to repro the problem by simulating a truncated keytab f= ile. vi /etc/krb5.keytab, use "$" to go to end of file. Use "x" to delet= e 40 or 50 characters from the end of the keytab file. Generate an updated keytab file, the new file becomes huge. Here is ls output showing typical results. This keytab file, when co= rrectly generated, should be about 2K in size. # ls -l krb5.keytab* -rw------- 1 root root 1140853107 Mar 7 17:58 krb5.keytab -rw------- 1 root root 1128810938 Mar 7 17:17 krb5.keytab.old -rw------- 1 root root 33082685 Mar 7 17:45 krb5.keytab.old2 -rw------- 1 root root 1128810930 Mar 7 17:49 krb5.keytab.old3 I got a backtrace of the process which was writing the keytab file,= here is the Kerberos library part Thread 1 (Thread 47272663262976 (LWP 19067)): #0 0x00002afe85edad8b in __write_nocancel () from /auto/home/lsbuild/desktop-187870/lib64/libc.so.6 #1 0x00002afe85e94aed in _IO_new_file_write () from /auto/home/lsbuild/desktop-187870/lib64/libc.so.6 #2 0x00002afe85e93bb5 in new_do_write () from /auto/home/lsbuild/desktop-187870/lib64/libc.so.6 #3 0x00002afe85e94c6f in _IO_new_file_xsputn () from /auto/home/lsbuild/desktop-187870/lib64/libc.so.6 #4 0x00002afe85e8aaf5 in fwrite () from /auto/home/lsbuild/desktop-187870/lib64/libc.so.6 #5 0x00002afe8589bcff in krb5_ktfileint_find_slot ( context=3D, id=3D0x59b7f0, size_needed=3D0x7fff282= 1cefc, commit_point=3D0x7fff2821cef8) at kt_file.c:1692 #6 0x00002afe8589bf1a in krb5_ktfileint_write_entry (context=3D0x599270, id=3D0x59b7f0, entry=3D0x7fff2821d010) at kt_file.c:1434 #7 0x00002afe8589c46f in krb5_ktfile_add (context=3D0x599270, id=3D0x59b7f= 0, entry=3D0x7fff2821d010) at kt_file.c:841 #8 0x00002afe86a1d88b in KtKrb5AddKey ( pszPrincipal=3D0x59a870 "cifs/CCM2.chaos.local@CHAOS.LOCAL", pKey=3D0x5= 9b870, dwKeyLen=3D16, pszSalt=3D0x59b8f0 "host/ccm2.chaos.local@CHAOS.LOCAL", pszKtPath=3D0x0, pszDcName=3D0x59b9e0 "qadc0.chaos.local", dwKeyVer=3D9= 60) at ddr/cifs/libkeytab/ktkrb5/keytab.c:332 #9 0x00002afe86a1e16b in KtKrb5AddKeyW (pwszPrincipal=3D0x59a340, pKey=3D0x550110, dwKeyLen=3D16, pwszKtPath=3D0x0, pwszSalt=3D0x59a820, pwszDcName=3D0x5181b0, dwKeyVersion=3D960) at ddr/cifs/libkeytab/ktkrb5/keytab_w16.c:87 >Fix: workaround: Delete the huge keytab and re-generate from scratch. --_000_C38669469756764EA77F5B406CE9AC7E326B812Fsjcexbe02DataDo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

SEND-PR: -*- sen= d-pr -*-

SEND-PR: Lines starting with `S= END-PR' will be removed automatically, as

SEND-PR: will all comments (text enclosed in `<' and `>').

SEND-PR:

SEND= -PR: Please consult the send-pr man page `send-pr(1)' or the Texinfo

SEND-PR: manual if you are not sure how to fil= l out a problem report.

SEND-PR:

SEND-PR: Choose from the following categories:<= o:p>

SEND-PR:

SEND-PR: krb5-admin   krb5-appl    krb5-build&= nbsp;  krb5-clients

SEND-PR: krb5-d= oc     krb5-kdc     krb5-libs =    krb5-misc

SEND-PR: pty = ;         telnet   &= nbsp;   test

SEND-PR:

To: krb5-bugs@mit.edu

Subject: /etc/krb5.keytab is 1Gb in size

From: sysadmin

Reply-To: sysad= min

Cc:

X-send-pr-version: 3.99

 

 

>= Submitter-Id:  net

>Originator:&= nbsp; Jim.Uren@EMC.com  &= nbsp;        

>Organization:  EMC Corporation

>Confidential:  no

>Synopsis:      Keytab file grows to 1Gb in s= ize

>Severity:    = ;  serious

>Priority:  = ;    medium

>Category:=       krb5-libs

>Class:         sw-bug

>Release:      = 1.4.1

>Environment:

        <machine, = os, target, libraries (multiple lines)>

System: Linux ccm2.chaos.local 2.6.23-ddr233377 #1 SMP Tue Mar 1 11:05:3= 1 PST 2011 x86_64 x86_64 x86_64 GNU/Linux

Architecture: x86_64

 =

>Description:

        Our product uses a CIFS server= provided by Likewise.com, which in turns ships its code with Kerberos.

        = We have seen a problem in which a huge /etc/krb5.keytab file is generated. = This seems to be due to non-robust error handling.

        The problem occurs = when the current keytab file is truncated, and the code generates a new key= tab file.

>How-To-Repeat:<= /p>

        We are a= ble to repro the problem by simulating a truncated keytab file.<= /p>

        vi /etc/= krb5.keytab, use “$” to go to end of file. Use “x” = to delete 40 or 50 characters from the end of the keytab file.

       Generate an upd= ated keytab file, the new file becomes huge.

       Here is ls output showing typical= results. This keytab file, when correctly generated, should be about 2K in= size.

# ls -l krb5.keytab*

-r= w-------  1 root root 1140853107 Mar  7 17:58 krb5.keytab

-rw-------  1 root root 1128810938 Mar  7 17:1= 7 krb5.keytab.old

-rw-------  1 root root&nb= sp;  33082685 Mar  7 17:45 krb5.keytab.old2

=

-rw-------  1 root root 1128810930 Mar  7 17:49 krb5.keytab.= old3

 

        I got a backtrace = of the process which was writing the keytab file, here is the Kerberos libr= ary part

Thread 1 (Thread 47272663262976 (LWP 19067)):
#0  0x00002afe85edad8b in __write_nocancel ()=

   from /auto/home/lsbuild/desktop-187870/lib64/=
libc.so.6
#1  0x00002afe85e94aed in _IO_new_file_=
write ()
   from /auto/home/lsbuild/desktop-=
187870/lib64/libc.so.6
#2  0x00002afe85e93bb5 in =
new_do_write ()
   from /auto/home/lsbuild/d=
esktop-187870/lib64/libc.so.6
#3  0x00002afe85e94=
c6f in _IO_new_file_xsputn ()
   from /auto/=
home/lsbuild/desktop-187870/lib64/libc.so.6
#4  0=
x00002afe85e8aaf5 in fwrite ()
   from /auto=
/home/lsbuild/desktop-187870/lib64/libc.so.6
#5  =
0x00002afe8589bcff in krb5_ktfileint_find_slot (
 =
;   context=3D<value optimized out>, id=3D0x59b7f0, size_ne=
eded=3D0x7fff2821cefc,
    commit_point=
=3D0x7fff2821cef8) at kt_file.c:1692
#6  0x00002a=
fe8589bf1a in krb5_ktfileint_write_entry (context=3D0x599270,
    id=3D0x59b7f0, entry=3D0x7fff2821d010) at kt_fil=
e.c:1434
#7  0x00002afe8589c46f in krb5_ktfile_ad=
d (context=3D0x599270, id=3D0x59b7f0,
  &nbs=
p; entry=3D0x7fff2821d010) at kt_file.c:841
#8  0=
x00002afe86a1d88b in KtKrb5AddKey (
   =
 pszPrincipal=3D0x59a870 "cifs/CCM2.chaos.local@CHAOS.LOCAL", pKe=
y=3D0x59b870,
    dwKeyLen=3D16, pszSal=
t=3D0x59b8f0 "host/ccm2.chaos.local@CHAOS.LOCAL",
    pszKtPath=3D0x0, pszDcName=3D0x59b9e0 "qadc0.=
chaos.local", dwKeyVer=3D960)
    =
at ddr/cifs/libkeytab/ktkrb5/keytab.c:332
#9  0x0=
0002afe86a1e16b in KtKrb5AddKeyW (pwszPrincipal=3D0x59a340,
    pKey=3D0x550110, dwKeyLen=3D16, pwszKtPath=3D0x0, =
pwszSalt=3D0x59a820,
    pwszDcName=3D0=
x5181b0, dwKeyVersion=3D960)
    at ddr=
/cifs/libkeytab/ktkrb5/keytab_w16.c:87
 
>Fix:
        workaround: Delete =
the huge keytab and re-generate from scratch.
= --_000_C38669469756764EA77F5B406CE9AC7E326B812Fsjcexbe02DataDo_--