Skip Menu |
 

Subject: Need a function to clone krb5_context structs for thread safe apps
krb5 library thread safety requires the use of a separate krb5_context
in each thread. Therefore, applications will require a method for
cloning krb5_contexts when allocating new threads
To: rt@krbdev.mit.edu
Cc:
Subject: Re: [krbdev.mit.edu #2856] Need a function to clone krb5_context structs for thread safe apps
From: Sam Hartman <hartmans@mit.edu>
Date: Mon, 27 Dec 2004 18:51:57 -0500
RT-Send-Cc:
It's important to note that applications need not free an object with
the same context used to acquire that object. The only case where
this is needed is if the application makes per-context configuration
changes.
Date: Mon, 27 Dec 2004 19:00:40 -0500
From: Jeffrey Altman <jaltman@columbia.edu>
To: rt-comment@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #2856] Need a function to clone krb5_context structs for thread safe apps
RT-Send-Cc:
Sam Hartman via RT wrote:

Show quoted text
> It's important to note that applications need not free an object with
> the same context used to acquire that object. The only case where
> this is needed is if the application makes per-context configuration
> changes.

I disagree. The claim has been made in response to ticket 2855 that
thread safety is only ensured if no two threads make calls into the
library using the same context at the same time. Therefore, there
must be one instance of the context for each thread.

If this is not the case, then the problem described in 2855 is in
fact a thread safety issue.
Download smime.p7s
application/x-pkcs7-signature 3.1KiB

Message body not shown because it is not plain text.

[jaltman@columbia.edu - Mon Dec 27 18:58:59 2004]:

Show quoted text
> Sam Hartman via RT wrote:
>
> > It's important to note that applications need not free an object with
> > the same context used to acquire that object. The only case where
> > this is needed is if the application makes per-context configuration
> > changes.
>
> I disagree. The claim has been made in response to ticket 2855 that
> thread safety is only ensured if no two threads make calls into the
> library using the same context at the same time. Therefore, there
> must be one instance of the context for each thread.
>
> If this is not the case, then the problem described in 2855 is in
> fact a thread safety issue.
>
>


My original intention with 2855 was to point out a potential race
condition - and the lack of locking. I do not feel that one needs
a separate context - unless one wants a different default realm for
each context... Note however, that krb5_parse_principal uses a static
default realm (retreived after krb5_get_default_realm) - which would
make it difficult....
Cc: Ken Raeburn <raeburn@mit.edu>, krb5-prs@mit.edu
From: Ken Raeburn <raeburn@MIT.EDU>
Subject: Re: [krbdev.mit.edu #2856] Need a function to clone krb5_context structs for thread safe apps
Date: Tue, 28 Dec 2004 18:47:43 -0500
To: rt@krbdev.mit.edu
RT-Send-Cc:
Download (untitled) / with headers
text/plain 1.2KiB
On Dec 28, 2004, at 07:13, Ezra Peisach via RT wrote:
Show quoted text
> [jaltman@columbia.edu - Mon Dec 27 18:58:59 2004]:
> My original intention with 2855 was to point out a potential race
> condition - and the lack of locking. I do not feel that one needs
> a separate context - unless one wants a different default realm for
> each context... Note however, that krb5_parse_principal uses a static
> default realm (retreived after krb5_get_default_realm) - which would
> make it difficult....

Good point -- and since we're caching the value in the context anyways,
there's no benefit in the one-context case. Might as well drop that
cache.

The restriction of using a krb5_context in only one thread at a time
has been one of the basic assumptions practically since the
thread-safety work was started. If we don't impose that restriction,
then we have to add a mutex to the context, and lock it on basically
every library call (except a few that don't use the context). I think
the list of types we're currently expecting to be
single-thread-at-a-time includes krb5_context, the auth context, the
GSS context, and the simple types like krb5_principal that we're
exposing and can't add a mutex to without changing the ABI.

Ken
To: rt@krbdev.mit.edu
Subject: [krbdev.mit.edu #2856] cloning contexts
From: Sam Hartman <hartmans@mit.edu>
Date: Tue, 28 Dec 2004 12:52:39 -0500
RT-Send-Cc:


In the case where no context-specific configuration changes are made,
krb5_init_ctx is a fine way to get a new context.

--Sam
From: tlyu@mit.edu
Subject: SVN Commit
* src/include/krb5/krb5.hin: Add prototype for krb5_copy_context.

* src/lib/krb5/krb/init_ctx.c (krb5_copy_context): New function to
copy/clone an existing krb5 context.
(copy_ktypes): Local helper function.

Commit By: tlyu



Revision: 18228
Changed Files:
U trunk/src/include/krb5/krb5.hin
U trunk/src/lib/krb5/krb/init_ctx.c
From: tlyu@mit.edu
Subject: SVN Commit
* src/lib/krb5_32.def: Export krb5_copy_context.

* src/lib/krb5/libkrb5.exports: Export krb5_copy_context.

* src/lib/krb5/krb/init_ctx.c (krb5_copy_context): Fix malloc
argument for nctx. Handle null default_ccname case.

Commit By: tlyu



Revision: 18229
Changed Files:
U trunk/src/lib/krb5/krb/init_ctx.c
U trunk/src/lib/krb5/libkrb5.exports
U trunk/src/lib/krb5_32.def
From: tlyu@mit.edu
Subject: SVN Commit
pull up r18228:18229 from trunk

r18228@cathode-dark-space: tlyu | 2006-06-26 17:03:04 -0400
ticket: 2856
tags: pullup

* src/include/krb5/krb5.hin: Add prototype for krb5_copy_context.

* src/lib/krb5/krb/init_ctx.c (krb5_copy_context): New function to
copy/clone an existing krb5 context.
(copy_ktypes): Local helper function.

r18229@cathode-dark-space: tlyu | 2006-06-26 18:04:51 -0400
ticket: 2856

* src/lib/krb5_32.def: Export krb5_copy_context.

* src/lib/krb5/libkrb5.exports: Export krb5_copy_context.

* src/lib/krb5/krb/init_ctx.c (krb5_copy_context): Fix malloc
argument for nctx. Handle null default_ccname case.


Commit By: tlyu



Revision: 18232
Changed Files:
U branches/krb5-1-5/src/include/krb5/krb5.hin
U branches/krb5-1-5/src/lib/krb5/krb/init_ctx.c
U branches/krb5-1-5/src/lib/krb5/libkrb5.exports
U branches/krb5-1-5/src/lib/krb5_32.def