Why cred_id_mutex?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Why cred_id_mutex?

Nico Williams
I don't understand why Heimdal's GSS cred handles have a mutex.  Can
someone explain that to me?

I understand having concurrent multi-threaded access to security
contexts for per-message tokens (wraps, MICs), because the mutable
state there is small (sequence number on the sender, sequence number
window on the receiver).

But I don't understand why we should allow concurrent calls to
gss_add_cred() to the same input cred handle.  That makes *no* sense
to me.  Remember, the GSS-API doesn't have a threaded model, but the
obvious thing to do is to say it's thread-safe as long as no more than
one thread is active in a GSS object at any time -- the only exception
worth making is for security contexts as to per-message tokens.

Please confirm or deny!  I will rip out the cred_id_mutex if no one
says anything!

(This can't be for Samba, right?  Because it's not threaded.)

Nico
--
Reply | Threaded
Open this post in threaded view
|

Re: Why cred_id_mutex?

Nico Williams
On Wed, Mar 18, 2015 at 11:25:37PM -0400, Jeffrey Altman wrote:

> The cred_id_mutex was added by
>
> commit 42f3fc029a072a69c57d10c756ffdf090adc7a90
> Author: Love Hörnquist Åstrand <[hidden email]>
> Date:   Wed May 21 14:52:14 2003 +0000
>
>     - do some basic locking (no reference counting so contexts can be
>       removed while still used)
>     - don't export gss_ctx_id_t_desc_struct and gss_cred_id_t_desc_struct
>     - make sure all lifetime are returned in seconds left until expired,
>       not in unix epoch
>
> Please wait for Love to explain whether or not it is still required.

Thanks.  I can imagine that OS X might need it, but I think we need to
have an explicit thread model for GSS, and multiple concurrent access to
any objects other than security contexts (and those only for per-message
tokens) is a bad idea.  (That doesn't mean we should have no locks
outside sec contexts.  There is still gsskrb5_register_acceptor_identity()
which has global state to mutate, and credential acquisition has to
lock around that state.)

A thread model is something that we're going to have to have agreement
on.  Otherwise divergence between implementors will cause users pain.

Nico
--
Reply | Threaded
Open this post in threaded view
|

Re: Why cred_id_mutex?

Jeffrey Hutzelman
On Thu, 2015-03-19 at 10:24 -0500, Nico Williams wrote:

> On Wed, Mar 18, 2015 at 11:25:37PM -0400, Jeffrey Altman wrote:
> > The cred_id_mutex was added by
> >
> > commit 42f3fc029a072a69c57d10c756ffdf090adc7a90
> > Author: Love Hörnquist Åstrand <[hidden email]>
> > Date:   Wed May 21 14:52:14 2003 +0000
> >
> >     - do some basic locking (no reference counting so contexts can be
> >       removed while still used)
> >     - don't export gss_ctx_id_t_desc_struct and gss_cred_id_t_desc_struct
> >     - make sure all lifetime are returned in seconds left until expired,
> >       not in unix epoch
> >
> > Please wait for Love to explain whether or not it is still required.
>
> Thanks.  I can imagine that OS X might need it, but I think we need to
> have an explicit thread model for GSS, and multiple concurrent access to
> any objects other than security contexts (and those only for per-message
> tokens) is a bad idea.  (That doesn't mean we should have no locks
> outside sec contexts.  There is still gsskrb5_register_acceptor_identity()
> which has global state to mutate, and credential acquisition has to
> lock around that state.)

If you have concurrent access to security contexts, you need concurrent
access to credentials.  Not necessarily concurrent _write_ access, but
you need to lock out writers during a read and vice versa.


> A thread model is something that we're going to have to have agreement
> on.  Otherwise divergence between implementors will cause users pain.

Yes.  That means it needs to go to kitten at some point.  And it needs
to have some way for applications to tell whether the GSS library is
compliant, since some probably never will be.

-- Jeff

Reply | Threaded
Open this post in threaded view
|

Re: Why cred_id_mutex?

Nico Williams
On Thu, Mar 19, 2015 at 02:49:46PM -0400, Jeffrey Hutzelman wrote:
> If you have concurrent access to security contexts, you need concurrent
> access to credentials.  Not necessarily concurrent _write_ access, but
> you need to lock out writers during a read and vice versa.

Not if the concurrent access to security contexts is just for
per-message tokens.

> > A thread model is something that we're going to have to have agreement
> > on.  Otherwise divergence between implementors will cause users pain.
>
> Yes.  That means it needs to go to kitten at some point.  And it needs
> to have some way for applications to tell whether the GSS library is
> compliant, since some probably never will be.

Yes, but first I want to know what depends on this, if anything.

Nico
--
Reply | Threaded
Open this post in threaded view
|

Re: Why cred_id_mutex?

Nico Williams
In reply to this post by Nico Williams
On Thu, Mar 19, 2015 at 01:44:56PM -0400, Matt W. Benjamin wrote:
> There seems to be code (RPCSEC_GSS) which effectively requires this
> exception.

The RPCSEC_GSS code should basically always use the default credential
handle.

Nico
--