[24090] in Kerberos
Re: Problems with ksu in krb5-1.4.1
daemon@ATHENA.MIT.EDU (Ken Raeburn)
Wed Jun 15 17:38:24 2005
In-Reply-To: <d8pq7s$1q11$1@grapevine.lcs.mit.edu>
Mime-Version: 1.0 (Apple Message framework v622)
Content-Type: multipart/mixed; boundary=Apple-Mail-7-976719013
Message-Id: <1851f25e40761b1336d53eeb684954c9@mit.edu>
From: Ken Raeburn <raeburn@mit.edu>
Date: Wed, 15 Jun 2005 17:19:16 -0400
To: wollman@khavrinen.csail.mit.edu (Garrett Wollman)
cc: kerberos@mit.edu
Errors-To: kerberos-bounces@mit.edu
--Apple-Mail-7-976719013
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=US-ASCII;
format=flowed
On Jun 15, 2005, at 13:58, Garrett Wollman wrote:
> In article <AD1D482E7127AF4AB30E2B3763F1E4A6017ED7@is051.atco.com>,
> Heilke, Rainer <Rainer.Heilke@atcoitek.com> wrote:
>
>> ksu does not appear to be doing anything odd to the credentials cache,
>> so why would the sessions freeze like this ?
>
> I wouldn't be surprised if it were related to the bug which causes
> this:
>
> wollman@isfahel(1)$ ksu
> Authenticated wollman@CSAIL.MIT.EDU
> Account root: authorization for wollman@CSAIL.MIT.EDU successful
> Changing uid to root (0)
> root@isfahel# exit
> Assertion failed: ((&_m->os)->initialized ==
> K5_MUTEX_DEBUG_INITIALIZED), function krb5_fcc_destroy, file
> cc_file.c, line 1526.
> Abort trap
I suspect they're different problems, but I'm investigating. I've just
run into the freezing problem on one of my machines.
For the assertion-failed problem, could you please try the attached
patch and let me know if it fixes it? (BTW, which OS is this on?)
Ken
--Apple-Mail-7-976719013
Content-Transfer-Encoding: 7bit
Content-Type: application/octet-stream;
x-unix-mode=0644;
name="pthread-detect-14.patch"
Content-Disposition: attachment;
filename=pthread-detect-14.patch
Index: include/k5-thread.h
===================================================================
RCS file: /cvs/krbdev/krb5/src/include/k5-thread.h,v
retrieving revision 1.22.2.2
diff -p -u -r1.22.2.2 k5-thread.h
--- include/k5-thread.h 24 Jan 2005 20:46:41 -0000 1.22.2.2
+++ include/k5-thread.h 1 Jun 2005 03:09:28 -0000
@@ -372,14 +372,8 @@ typedef k5_os_nothread_mutex k5_os_mutex
# ifdef HAVE_PTHREAD_MUTEXATTR_SETROBUST_NP_IN_THREAD_LIB
# pragma weak pthread_mutexattr_setrobust_np
# endif
-# if !defined HAVE_PTHREAD_ONCE
-# define K5_PTHREADS_LOADED (&pthread_once != 0)
-# elif !defined HAVE_PTHREAD_MUTEXATTR_SETROBUST_NP \
- && defined HAVE_PTHREAD_MUTEXATTR_SETROBUST_NP_IN_THREAD_LIB
-# define K5_PTHREADS_LOADED (&pthread_mutexattr_setrobust_np != 0)
-# else
-# define K5_PTHREADS_LOADED (1)
-# endif
+extern int krb5int_pthread_loaded(void);
+# define K5_PTHREADS_LOADED (krb5int_pthread_loaded())
#else
/* no pragma weak support */
# define K5_PTHREADS_LOADED (1)
@@ -404,6 +398,8 @@ typedef k5_os_nothread_mutex k5_os_mutex
#endif
#if !defined(HAVE_PTHREAD_MUTEX_LOCK) && !defined(USE_PTHREAD_LOCK_ONLY_IF_LOADED)
+/* If we find a system with a broken stub for pthread_mutex_lock,
+ we may have to change this. */
# define USE_PTHREAD_LOCK_ONLY_IF_LOADED
#endif
Index: util/support/libkrb5support.exports
===================================================================
RCS file: /cvs/krbdev/krb5/src/util/support/libkrb5support.exports,v
retrieving revision 1.3
diff -p -u -r1.3 libkrb5support.exports
--- util/support/libkrb5support.exports 25 Oct 2004 19:09:54 -0000 1.3
+++ util/support/libkrb5support.exports 1 Jun 2005 03:09:30 -0000
@@ -5,3 +5,4 @@ krb5int_setspecific
krb5int_fac
krb5int_lock_fac
krb5int_unlock_fac
+krb5int_pthread_loaded
Index: util/support/threads.c
===================================================================
RCS file: /cvs/krbdev/krb5/src/util/support/threads.c,v
retrieving revision 1.11.4.3
diff -p -u -r1.11.4.3 threads.c
--- util/support/threads.c 23 Mar 2005 03:58:01 -0000 1.11.4.3
+++ util/support/threads.c 1 Jun 2005 03:09:30 -0000
@@ -106,6 +106,61 @@ struct tsd_block {
# pragma weak pthread_setspecific
# pragma weak pthread_key_create
# pragma weak pthread_key_delete
+# pragma weak pthread_create
+# pragma weak pthread_join
+static volatile int flag_pthread_loaded = -1;
+static void loaded_test_aux(void)
+{
+ if (flag_pthread_loaded == -1)
+ flag_pthread_loaded = 1;
+ else
+ /* Could we have been called twice? */
+ flag_pthread_loaded = 0;
+}
+static pthread_once_t loaded_test_once = PTHREAD_ONCE_INIT;
+int krb5int_pthread_loaded (void)
+{
+ int x = flag_pthread_loaded;
+ if (x != -1)
+ return x;
+ if (&pthread_getspecific == 0
+ || &pthread_setspecific == 0
+ || &pthread_key_create == 0
+ || &pthread_key_delete == 0
+ || &pthread_once == 0
+ || &pthread_mutex_lock == 0
+ || &pthread_mutex_unlock == 0
+ || &pthread_mutex_destroy == 0
+ || &pthread_mutex_init == 0
+ || &pthread_self == 0
+ || &pthread_equal == 0
+ /* This catches Solaris 9. May be redundant with the above
+ tests now. */
+# ifdef HAVE_PTHREAD_MUTEXATTR_SETROBUST_NP_IN_THREAD_LIB
+ || &pthread_mutexattr_setrobust_np == 0
+# endif
+ /* Any program that's really multithreaded will have to be
+ able to create threads. */
+ || &pthread_create == 0
+ || &pthread_join == 0
+ /* Okay, all the interesting functions -- or stubs for them --
+ seem to be present. If we call pthread_once, does it
+ actually seem to cause the indicated function to get called
+ exactly one time? */
+ || pthread_once(&loaded_test_once, loaded_test_aux) != 0
+ || pthread_once(&loaded_test_once, loaded_test_aux) != 0
+ /* This catches cases where pthread_once does nothing, and
+ never causes the function to get called. That's a pretty
+ clear violation of the POSIX spec, but hey, it happens. */
+ || flag_pthread_loaded < 0) {
+ flag_pthread_loaded = 0;
+ return 0;
+ }
+ /* If we wanted to be super-paranoid, we could try testing whether
+ pthread_get/setspecific work, too. I don't know -- so far --
+ of any system with non-functional stubs for those. */
+ return flag_pthread_loaded;
+}
static struct tsd_block tsd_if_single;
# define GET_NO_PTHREAD_TSD() (&tsd_if_single)
#else
--Apple-Mail-7-976719013
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=US-ASCII;
format=flowed
--Apple-Mail-7-976719013
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
--Apple-Mail-7-976719013--
