From rt-comment at krbdev.mit.edu Thu May 1 02:18:14 2008 From: rt-comment at krbdev.mit.edu (Russ Allbery via RT) Date: Thu, 1 May 2008 02:18:14 -0400 (EDT) Subject: [krbdev.mit.edu #5957] fakeka requires master key be DES In-Reply-To: Message-ID: fakeka initializes the DES random number generator with the key block of the master key. This seems a bit questionable, if not obviously broken, in the first place, but it also retrieves the key with the following code: if ((code = kadm5_decrypt_key(handle, &master_princ_rec, ENCTYPE_DES_CBC_CRC, -1, 0, &mkey, NULL, NULL))) { com_err(argv[0], code, "while decrypting the master key"); exit(1); } This breaks if K/M has no des-cbc-crc key (such as with a newly built KDC with a 3DES master key). I discussed this briefly with Sam on Zephyr and he suggested just removing the enctype restriction on the key retrieval and passing whatever you got back into the des random seed function, since any other key is going to be at least as long as a DES key. However, more fundamentally, I think this is broken. Among other things, the master key basically never changes, thus making it a poor choice for a random seed. I expect there's some other function in the Kerberos libraries that already retrieves some random data from a system service such as /dev/random. That should be used here as well. From rt-comment at krbdev.mit.edu Thu May 1 02:28:25 2008 From: rt-comment at krbdev.mit.edu (Russ Allbery via RT) Date: Thu, 1 May 2008 02:28:25 -0400 (EDT) Subject: [krbdev.mit.edu #5958] kadmin enctype naming for DES is deceptive In-Reply-To: Message-ID: In the current kadmin, "DES cbc mode with CRC-32, no salt" is in fact salted with the default v5 salt method, whereas "DES cbc mode with CRC-32, Version 4" is actually not salted. I don't think this could be more confusing if it was designed to be as confusing as possible. :) Solving 5014 would help here, but only partly. The basic problem is that :normal does not actually mean no salt, but that's how it's displayed. Perhaps that string in the kadmin client should be changed to "default salt" instead? From rt-comment at krbdev.mit.edu Thu May 1 02:34:43 2008 From: rt-comment at krbdev.mit.edu (Russ Allbery via RT) Date: Thu, 1 May 2008 02:34:43 -0400 (EDT) Subject: [krbdev.mit.edu #5959] Missing fakeka documentation In-Reply-To: Message-ID: fakeka's man page could use some additional details about what's required for it to work and some expansion of the details already mentioned. I can probably contribute the additional documentation, but I want to get this into a ticket while it's all fresh in my mind. First, while it mentions that you need des:v4 or des:afs3, that could be expanded a bit. Specifically, AFS klog first tries an :afs3 salt using the cell name as the realm for the salt, and then tries :v4 (no salt). If your Kerberos realm and AFS cell names match, either des-cbc-crc:afs3 or des-cbc-crc:v4 keys will work. If the realm names do not match, you have to use des-cbc-crc:v4 keys. Only users with those keys will be able to klog using fakeka. It's worth mentioning explicitly that des-cbc-crc:normal will not work and that that's the v5 salt. Second, the AFS key must exist in the Kerberos KDC database as a DES key (the salt doesn't matter), and that must match (including kvno) what's in the KeyFile on the AFS servers. This principal may be "afs" if the realm and cell names match, but generally should be afs/cell.name. Third, if the Kerberos realm name and AFS cell name do not match, you must also create a krbtgt/CELL.NAME principal in your KDC database with a DES key (any salt). The key can be random and doesn't have to be synchronized with anything else; it just has to exist for klog to work properly because klog first does an Authenticate call to get a krbtgt and then does a GetTickets call to get the afs service ticket. From rt-comment at krbdev.mit.edu Wed May 7 15:30:28 2008 From: rt-comment at krbdev.mit.edu (Alexandra Ellwood via RT) Date: Wed, 7 May 2008 15:30:28 -0400 (EDT) Subject: [krbdev.mit.edu #5960] SVN Commit In-Reply-To: Message-ID: Moved sources and headers. Commit By: lxs Revision: 20314 Changed Files: A trunk/src/include/kim/ A trunk/src/include/kim/kim.h A trunk/src/include/kim/kim_ccache.h A trunk/src/include/kim/kim_credential.h A trunk/src/include/kim/kim_error.h A trunk/src/include/kim/kim_identity.h A trunk/src/include/kim/kim_options.h A trunk/src/include/kim/kim_preferences.h A trunk/src/include/kim/kim_selection_hints.h A trunk/src/include/kim/kim_string.h A trunk/src/include/kim/kim_types.h A trunk/src/kim/ A trunk/src/kim/agent/ A trunk/src/kim/agent/mac/ A trunk/src/kim/agent/mac/KerberosAgent-Info.plist A trunk/src/kim/agent/mac/KerberosAgentPrefix.pch A trunk/src/kim/agent/mac/main.m A trunk/src/kim/agent/mac/resources/ A trunk/src/kim/agent/mac/resources/Add.tiff A trunk/src/kim/agent/mac/resources/Add_Pressed.tiff A trunk/src/kim/agent/mac/resources/English.lproj/ A trunk/src/kim/agent/mac/resources/English.lproj/Authentication.xib A trunk/src/kim/agent/mac/resources/English.lproj/MainMenu.xib A trunk/src/kim/agent/mac/resources/Gear.tiff A trunk/src/kim/agent/mac/resources/KerberosAgent.icns A trunk/src/kim/agent/mac/resources/Remove.tiff A trunk/src/kim/agent/mac/resources/Remove_Pressed.tiff A trunk/src/kim/lib/ A trunk/src/kim/lib/kim.exports A trunk/src/kim/lib/kim_ccache.c A trunk/src/kim/lib/kim_ccache_private.h A trunk/src/kim/lib/kim_credential.c A trunk/src/kim/lib/kim_error.c A trunk/src/kim/lib/kim_error_code.et A trunk/src/kim/lib/kim_error_private.h A trunk/src/kim/lib/kim_identity.c A trunk/src/kim/lib/kim_identity_private.h A trunk/src/kim/lib/kim_library.c A trunk/src/kim/lib/kim_library_private.h A trunk/src/kim/lib/kim_options.c A trunk/src/kim/lib/kim_options_private.h A trunk/src/kim/lib/kim_preferences.c A trunk/src/kim/lib/kim_preferences_private.h A trunk/src/kim/lib/kim_private.h A trunk/src/kim/lib/kim_selection_hints.c A trunk/src/kim/lib/kim_selection_hints_private.h A trunk/src/kim/lib/kim_string.c A trunk/src/kim/lib/kim_string_private.h A trunk/src/kim/lib/mac/ A trunk/src/kim/lib/mac/kim_os_identity.c A trunk/src/kim/lib/mac/kim_os_library.c A trunk/src/kim/lib/mac/kim_os_preferences.c A trunk/src/kim/lib/mac/kim_os_private.h A trunk/src/kim/lib/mac/kim_os_selection_hints.c A trunk/src/kim/lib/mac/kim_os_string.c A trunk/src/kim/test/ A trunk/src/kim/test/main.c A trunk/src/kim/test/test_kim_common.c A trunk/src/kim/test/test_kim_common.h A trunk/src/kim/test/test_kim_identity.c A trunk/src/kim/test/test_kim_identity.h A trunk/src/kim/test/test_kim_preferences.c A trunk/src/kim/test/test_kim_preferences.h A trunk/src/kim/test/test_kim_selection_hints.c A trunk/src/kim/test/test_kim_selection_hints.h From rt-comment at krbdev.mit.edu Wed May 7 15:40:40 2008 From: rt-comment at krbdev.mit.edu (Alexandra Ellwood via RT) Date: Wed, 7 May 2008 15:40:40 -0400 (EDT) Subject: [krbdev.mit.edu #5960] SVN Commit In-Reply-To: Message-ID: Added kim documentation. Commit By: lxs Revision: 20315 Changed Files: A trunk/doc/kim/ A trunk/doc/kim/Doxyfile A trunk/doc/kim/html/ A trunk/doc/kim/html/doxygen.css A trunk/doc/kim/html/doxygen.png A trunk/doc/kim/html/group__kim__ccache__iterator__reference.html A trunk/doc/kim/html/group__kim__ccache__reference.html A trunk/doc/kim/html/group__kim__credential__iterator__reference.html A trunk/doc/kim/html/group__kim__credential__reference.html A trunk/doc/kim/html/group__kim__error__reference.html A trunk/doc/kim/html/group__kim__favorite__identities__reference.html A trunk/doc/kim/html/group__kim__identity__reference.html A trunk/doc/kim/html/group__kim__options__reference.html A trunk/doc/kim/html/group__kim__preferences__reference.html A trunk/doc/kim/html/group__kim__selection__hints__reference.html A trunk/doc/kim/html/group__kim__string__reference.html A trunk/doc/kim/html/group__kim__types__reference.html A trunk/doc/kim/html/index.html A trunk/doc/kim/html/kim_ccache_overview.html A trunk/doc/kim/html/kim_credential_overview.html A trunk/doc/kim/html/kim_error_overview.html A trunk/doc/kim/html/kim_favorite_identities_overview.html A trunk/doc/kim/html/kim_identity_overview.html A trunk/doc/kim/html/kim_options_overview.html A trunk/doc/kim/html/kim_preferences_overview.html A trunk/doc/kim/html/kim_selection_hints_overview.html A trunk/doc/kim/html/kim_string_overview.html A trunk/doc/kim/html/modules.html A trunk/doc/kim/html/tab_b.gif A trunk/doc/kim/html/tab_l.gif A trunk/doc/kim/html/tab_r.gif A trunk/doc/kim/html/tabs.css From rt-comment at krbdev.mit.edu Wed May 7 15:41:46 2008 From: rt-comment at krbdev.mit.edu (Alexandra Ellwood via RT) Date: Wed, 7 May 2008 15:41:46 -0400 (EDT) Subject: [krbdev.mit.edu #5960] SVN Commit In-Reply-To: Message-ID: Removed kim from the KfM repository. Commit By: lxs Revision: 6405 Changed Files: D trunk/KerberosFramework/KerberosIdentityManagement/ From rt-comment at krbdev.mit.edu Wed May 7 15:44:57 2008 From: rt-comment at krbdev.mit.edu (Alexandra Ellwood via RT) Date: Wed, 7 May 2008 15:44:57 -0400 (EDT) Subject: [krbdev.mit.edu #5960] SVN Commit In-Reply-To: Message-ID: Updated KfM build system for new kim location. Commit By: lxs Revision: 6406 Changed Files: U trunk/KerberosFramework/Common/Projects/KerberosFramework.xcodeproj/project.pbxproj U trunk/KerberosFramework/Kerberos5/Headers/Kerberos5Prefix.h U trunk/KerberosFramework/Kerberos5/Projects/Kerberos5.xcodeproj/project.pbxproj From rt-comment at krbdev.mit.edu Sat May 10 23:55:01 2008 From: rt-comment at krbdev.mit.edu (Russ Allbery via RT) Date: Sat, 10 May 2008 23:55:01 -0400 (EDT) Subject: [krbdev.mit.edu #5544] SVN Commit In-Reply-To: Message-ID: Fix a typo in krb5.conf: ldap_server should be ldap_servers, as the latter is what the LDAP KDB plugin looks for. Commit By: rra Revision: 20316 Changed Files: U trunk/src/config-files/krb5.conf.M From rt-comment at krbdev.mit.edu Sat May 10 23:50:29 2008 From: rt-comment at krbdev.mit.edu (Russ Allbery via RT) Date: Sat, 10 May 2008 23:50:29 -0400 (EDT) Subject: [krbdev.mit.edu #3059] spurious EBADF in krshd In-Reply-To: Message-ID: I took a look at this ticket, but I can't find any instance of "write_to" in bsd/krshd.c or a mention of its previous existence in its history. Is this problem perhaps dependent on some other patch? From rt-comment at krbdev.mit.edu Mon May 12 15:33:10 2008 From: rt-comment at krbdev.mit.edu (The RT System itself via RT) Date: Mon, 12 May 2008 15:33:10 -0400 (EDT) Subject: [krbdev.mit.edu #5961] ftp client breaks when case-mapping is enabled In-Reply-To: Message-ID: >From krb5-bugs-incoming-bounces at PCH.MIT.EDU Mon May 12 15:33:04 2008 Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by krbdev.mit.edu (8.12.9) with ESMTP id m4CJX2HW002428; Mon, 12 May 2008 15:33:02 -0400 (EDT) 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 m4CJWv85027421; Mon, 12 May 2008 15:32:57 -0400 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m4CIJ697007560 for ; Mon, 12 May 2008 14:19:06 -0400 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m4CIIwma028347 for ; Mon, 12 May 2008 14:18:59 -0400 (EDT) X-ASG-Whitelist: Barracuda Reputation Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by mit.edu (Spam Firewall) with ESMTP id B8D9810F00EC for ; Mon, 12 May 2008 14:18:58 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m4CIIwKi028453 for ; Mon, 12 May 2008 14:18:58 -0400 Received: from blade.bos.redhat.com (blade.bos.redhat.com [10.16.0.23]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m4CIIvK8012101 for ; Mon, 12 May 2008 14:18:57 -0400 Received: from blade.bos.redhat.com (localhost.localdomain [127.0.0.1]) by blade.bos.redhat.com (8.14.2/8.14.2) with ESMTP id m4CIIvaG027328 for ; Mon, 12 May 2008 14:18:57 -0400 Received: (from nalin at localhost) by blade.bos.redhat.com (8.14.2/8.14.2/Submit) id m4CIIv9S027326; Mon, 12 May 2008 14:18:57 -0400 Date: Mon, 12 May 2008 14:18:57 -0400 Message-Id: <200805121818.m4CIIv9S027326 at blade.bos.redhat.com> To: krb5-bugs at mit.edu From: nalin at redhat.com X-send-pr-version: 3.99 X-Scanned-By: MIMEDefang 2.42 X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 X-Spam-Score: 6.278 X-Spam-Level: ****** (6.278) X-Spam-Flag: NO X-Mailman-Approved-At: Mon, 12 May 2008 15:32:56 -0400 X-BeenThere: krb5-bugs-incoming at mailman.mit.edu X-Mailman-Version: 2.1.6 Precedence: list Reply-To: nalin at redhat.com Sender: krb5-bugs-incoming-bounces at PCH.MIT.EDU Errors-To: krb5-bugs-incoming-bounces at PCH.MIT.EDU >Submitter-Id: net >Originator: Nalin Dahyabhai >Organization: >Confidential: no >Synopsis: ftp client breaks when case-mapping is enabled >Severity: non-critical >Priority: medium >Category: krb5-appl >Class: sw-bug >Release: 1.6.3 >Environment: System: Linux blade.bos.redhat.com 2.6.25-14.fc9.x86_64 #1 SMP Thu May 1 06:06:21 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux Architecture: x86_64 >Description: When "case" is enabled, the FTP client sets the local (target) filename to the buffer in which it stores the generated lower-cased version of the file's name, even it ended up not generating a lower-cased version of the name, causing the client to store the incoming data in whichever file whose name it had last generated. >How-To-Repeat: Create these files in a space you can get to using the FTP client: Test1.out1 TEST2.OUT2 tesT3.Out3 TEST4.OUT4 Now ftp in, switch on case-mapping (with the "case" command), and attempt to retrieve the three files using "mget". You may end up with files named "test2.out2" and "test4.out4", if the server sends them in this order: (remote) (local) TEST2.OUT2 -> test2.out2 TEST4.OUT4 -> test4.out4 Test1.out1 -> test4.out4 tesT3.Out3 -> test4.out4 >Fix: This patch fixes it for me: diff -up src/appl/gssftp/ftp/cmds.c src/appl/gssftp/ftp/cmds.c --- src/appl/gssftp/ftp/cmds.c +++ src/appl/gssftp/ftp/cmds.c @@ -1013,8 +1013,10 @@ void mget(argc, argv) tp++; tp2++; } + tp = tmpbuf; + } else { + tp = cp; } - tp = tmpbuf; } if (ntflag) { tp = dotrans(tp); From rt-comment at krbdev.mit.edu Mon May 12 15:34:48 2008 From: rt-comment at krbdev.mit.edu (nalin@redhat.com via RT) Date: Mon, 12 May 2008 15:34:48 -0400 (EDT) Subject: [krbdev.mit.edu #5961] AutoReply: ftp client breaks when case-mapping is enabled In-Reply-To: Message-ID: Aaargh. Please close this as a duplicate of #5940, which I missed when I was searching to check whether or not I'd already reported this bug. Sorry for any confusion, Nalin From rt-comment at krbdev.mit.edu Thu May 15 19:15:36 2008 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Thu, 15 May 2008 19:15:36 -0400 (EDT) Subject: [krbdev.mit.edu #5962] unchecked calls to k5_mutex_lock() interact poorly with finalizers In-Reply-To: Message-ID: We need to ensure that all calls to k5_mutex_lock() check the return values, to avoid assertion failures when the lock attempt fails and k5_mutex_unlock() then does its consistency checks. This can happen if finalizers destroy the mutex before the call to k5_mutex_lock(). It is also not safe to operate on shared data if k5_mutex_lock() fails, so we should do something reasonable in that situation anyway. From: Alexandra Ellwood Date: Thu, 15 May 2008 17:15:12 -0400 I think I have figured it out. Sadly it's hard to fix completely, but there is a relatively easy fix which should reduce the number of these reports. So the key that tipped me off was looking at the full crash log. Obviously there's our poor crashed thread which is calling assert because it doesn't actually own the lock it just locked. Or, to be precise, pthread_equal((&(&g_mechListLock)->os)->owner, pthread_self()) is returning false: Thread 16 Crashed: 0 libSystem.B.dylib 0x92e8e17a usleep$NOCANCEL$UNIX2003 + 0 1 libSystem.B.dylib 0x92eaf9bb abort + 85 2 libSystem.B.dylib 0x92ea1593 __assert_rtn + 101 3 edu.mit.Kerberos 0x96bdb4d4 gssint_get_mechanism + 323 4 edu.mit.Kerberos 0x96b60508 gss_init_sec_context + 133 5 sncgss.dyld 0x0592b680 sapgss_init_sec_context + 779 6 libJPlatin.jnilib 0x12eed293 SncPEstablishContext + 321 7 libJPlatin.jnilib 0x12ef06aa SncPFrameIn + 7632 8 libJPlatin.jnilib 0x12ee426b SncProcessInput + 921 9 libJPlatin.jnilib 0x12edcd30 TmRead + 2321 10 libJPlatin.jnilib 0x12e5a742 AgCom::Read(unsigned char*, int, int*) + 154 11 libJPlatin.jnilib 0x12e5a890 AgCom::CsRead(unsigned char*, int, int*, int) + 146 12 libJPlatin.jnilib 0x12d9e73e AgComAdaptor::read(unsigned char**, int*) + 196 13 libJPlatin.jnilib 0x12d9b674 Java_com_sap_platin_r3_protocol_ni_JniAgComAdaptor_jniRead + 58 14 ??? 0x035859b1 0 + 56121777 15 ??? 0x0357fa54 0 + 56097364 16 ??? 0x0357faaa 0 + 56097450 17 ??? 0x0357d227 0 + 56087079 18 libjvm.dylib 0x004d263a 0x3b9000 + 1152570 19 libjvm.dylib 0x00416763 0x3b9000 + 382819 20 libjvm.dylib 0x00416655 0x3b9000 + 382549 21 libjvm.dylib 0x00416595 0x3b9000 + 382357 22 libjvm.dylib 0x004164b8 0x3b9000 + 382136 23 libjvm.dylib 0x0067dcc5 JVM_RaiseSignal + 441189 24 libSystem.B.dylib 0x92e3753b _pthread_body + 27 However, scrolling up a bit we find this thread: Thread 3: 0 libSystem.B.dylib 0x92dba9e6 mach_msg_trap + 10 1 libSystem.B.dylib 0x92dc21dc mach_msg + 72 2 libSystem.B.dylib 0x92dc1fe0 vproc_mig_look_up2 + 198 3 libSystem.B.dylib 0x92dc1ea0 bootstrap_look_up2 + 73 4 libSystem.B.dylib 0x92dc1e55 bootstrap_look_up + 55 5 edu.mit.Kerberos 0x96b6ffd4 kipc_client_lookup_server + 327 6 edu.mit.Kerberos 0x96b693ed cci_os_ipc + 264 7 edu.mit.Kerberos 0x96b691ba _cci_ipc_send + 221 8 edu.mit.Kerberos 0x96b692bf cci_ipc_send_no_launch + 39 9 edu.mit.Kerberos 0x96b65b39 cci_context_sync + 181 10 edu.mit.Kerberos 0x96b66bce ccapi_context_release + 33 11 edu.mit.Kerberos 0x96b62a07 krb5_stdcc_shutdown + 30 12 edu.mit.Kerberos 0x96b4eb51 krb5int_lib_fini + 267 13 dyld 0x8fe12fc3 ImageLoaderMachO::doTermination(ImageLoader::LinkContext const&) + 227 14 dyld 0x8fe04f7b dyld::runTerminators(void*) + 155 15 libSystem.B.dylib 0x92de353c __cxa_finalize + 241 16 libSystem.B.dylib 0x92de3430 exit + 33 17 libjvm.dylib 0x00473ba3 0x3b9000 + 764835 18 libjvm.dylib 0x00473b02 0x3b9000 + 764674 19 libjvm.dylib 0x004739c8 0x3b9000 + 764360 20 libjvm.dylib 0x0041603d 0x3b9000 + 380989 21 libjvm.dylib 0x00415d57 0x3b9000 + 380247 22 libjvm.dylib 0x0067dcc5 JVM_RaiseSignal + 441189 23 libSystem.B.dylib 0x92e3753b _pthread_body + 27 Uh oh. SAPGUI is in the middle of exiting and is running the library finalizer for the krb5 library. Unfortunately this probably isn't the only library finalizer it has run. Chances are good that this thread has already run the finalizer for the GSS library... After talking to Ken Raeburn, here's what we think is happening: Thread 16 enters gssint_get_mechanism() and calls gssint_initialize_library(). This function verifies the library is loaded and g_mechListLock is valid. Meanwhile the application is trying to quit due to some error or user action. Thread 3 calls exit() which calls dyld::runTerminators(). This runs the GSS library finalizer which calls pthread_mutex_destroy() on g_mechListLock, invalidating the lock which thread 16 is about to use. Thread 3 then proceeds on to the krb5 library finalizer which blocks on a Mach-IPC call to the CCacheServer. Meanwhile, thread 16 calls calls k5_mutex_lock() which returns an error because g_mechListLock has been destroyed by thread 3. Unfortunately, gssint_get_mechanism() discards the error from k5_mutex_lock() and continues. When it calls k5_mutex_unlock() the owner is not set (because g_mechListLock was not locked) and thus we get an assertion failure. Now this particular problem can be easily fixed by making sure our code checks the return value of k5_mutex_lock() everywhere it is called and does not call k5_mutex_unlock() if k5_mutex_lock() fails. After making this change there are probably still similar race conditions which need to be analyzed. I want to look at all of the crash logs to make sure there are not other common scenarios which cause similar race conditions. Note that just ignoring the already-destroyed mutex isn't really safe because we could end up garbling memory and potentially spewing it out on the network before the application manages to exit. So just removing the assert() calls isn't really a good idea. Application crash on exit is bad, but better than a security hole. :-) --lxs Alexandra Ellwood MIT Kerberos Consortium From rt-comment at krbdev.mit.edu Fri May 16 21:11:56 2008 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Fri, 16 May 2008 21:11:56 -0400 (EDT) Subject: [krbdev.mit.edu #5943] SVN Commit In-Reply-To: Message-ID: Force hostname to lowercase before constructing kadmin principal name. Allocate space for the name dynamically. Commit By: raeburn Revision: 20323 Changed Files: U trunk/src/kadmin/dbutil/kadm5_create.c From rt-comment at krbdev.mit.edu Mon May 19 14:12:58 2008 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Mon, 19 May 2008 14:12:58 -0400 (EDT) Subject: [krbdev.mit.edu #5899] SVN Commit In-Reply-To: Message-ID: Use $(DL_LIB) instead of explicit -ldl. Commit By: raeburn Revision: 20325 Changed Files: U trunk/src/plugins/preauth/pkinit/Makefile.in From rt-comment at krbdev.mit.edu Thu May 22 17:00:51 2008 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Thu, 22 May 2008 17:00:51 -0400 (EDT) Subject: [krbdev.mit.edu #5937] memory leak when credential delegation In-Reply-To: Message-ID: Fixed by lxs in rev 17997, for the 1.5 releases. From rt-comment at krbdev.mit.edu Tue May 27 12:26:03 2008 From: rt-comment at krbdev.mit.edu (Alexandra Ellwood via RT) Date: Tue, 27 May 2008 12:26:03 -0400 (EDT) Subject: [krbdev.mit.edu #5963] SVN Commit In-Reply-To: Message-ID: Call rw_access lazily so we only call access just before we need to write to the file to avoid calling access as often. Deprecated bit in profile structures to track writability. Commit By: lxs Revision: 20341 Changed Files: U trunk/src/util/profile/prof_file.c U trunk/src/util/profile/prof_init.c U trunk/src/util/profile/prof_int.h From rt-comment at krbdev.mit.edu Tue May 27 23:51:31 2008 From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT) Date: Tue, 27 May 2008 23:51:31 -0400 (EDT) Subject: [krbdev.mit.edu #5964] Re: Fwd: [modauthkerb] [SOLVED] 'Request is a replay' + Basic auth In-Reply-To: Message-ID: Hank: Thanks for this. The analysis is slightly wrong but the end result is correct. The 'authtime' value has one second accuracy. As a result when it is used as input to krb5_set_real_time() which has microsecond accuracy the current microseconds value from the system clock is rounded off. The end result is an increased likelihood that there will be collisions. krb5_set_real_time() is only called from within verify_as_reply() as is therefore only used with input values with one second accuracy. I believe the correct fix is to modify krb5_set_real_time() to ignore the microseconds input value. Jeffrey Altman bcc: krb5-bugs Henry B. Hotz wrote: > Hope this is of some use. > > Begin forwarded message: > >> From: Enrico Scholz >> Date: April 7, 2007 11:24:55 AM EDT >> To: modauthkerb-help at lists.sourceforge.net >> Subject: [modauthkerb] [SOLVED] 'Request is a replay' + Basic auth >> >> Hello, >> >> I had a longstanding problem that mod_auth_kerb failed with >> >> | Request is a replay >> >> when doing Basic Auth and making lot of requests (e.g. SVN, webpages >> with much images). >> >> The problem was the setting of >> >> | [defaults] >> | kdc_timesync = 1 >> >> in /etc/krb5.conf. Turning it off seems to make things work fine. >> >> >> Explanation: The option above is used to correct timestamps of tickets. >> Unfortunately, MIT KRB5 (1.4 - 1.6) uses a precision of one second for >> this calibration[1] while the system time (which is e.g. used for >> creating >> tickets) uses a precision of microseconds. >> >> Now, the following happens: >> >> 1. Client verifies KDC >> >> 2. Client receives an authtime reply from the KDC >> >> Time in reply might be 1175958621 seconds >> Time at client might be 1175958621 seconds and 900000 microseconds >> >> 3. Client will now use corrected times by subtracting 900000 >> microseconds >> from the system time >> >> 4. 100 microseconds later, the client requests the ticket >> >> Time at client is now 1175958621 seconds and 900100 microseconds >> Corrected time in ticket is 1175958621 seconds and 100 microseconds >> >> 5. The same steps happens in e.g. 10 other threads. Since time between >> 2. and 4. will be nearly constant (same code will be executed), it is >> very likely that two tickets with the same timestamp will be >> requested. >> >> This results into the 'Request is a replay' error. >> >> >> Turning off the time calibration ensures that ticket time is different >> for all threads (scheduling needs more than 1 us for task switching >> and krb5 tries to handle this too). >> >> >> >> Enrico >> >> Footnotes: >> [1] See lib/krb5/krb/get_in_tkt.c which makes >> | krb5_set_real_time(context, >> | as_reply->enc_part2->times.authtime, 0); >> ~~~~~~~~~~~~ seconds ~~~~~~~~~~~~~~ ~us~ >> >> ------------------------------------------------------------------------- >> >> Take Surveys. Earn Cash. Influence the Future of IT >> Join SourceForge.net's Techsay panel and you'll get the chance to >> share your >> opinions on IT & business topics through brief surveys-and earn cash >> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________ >> >> modauthkerb-help mailing list >> modauthkerb-help at lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/modauthkerb-help >