Bug 1740 - Implicit module activiation
: Implicit module activiation
Status: CLOSED FIXED
: GSI C
Authentication
: unspecified
: PC Linux
: P2 major
: ---
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2004-05-13 11:36 by
Modified: 2008-08-11 15:18 (History)


Attachments
test snippit for gssapi (2.91 KB, text/plain)
2004-05-14 11:17, David Smith
Details
gcc snippit to compile t.c (783 bytes, text/plain)
2004-05-14 11:17, David Smith
Details
Patch for bug (4.86 KB, patch)
2004-06-04 09:05, Sam Meder
Details


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2004-05-13 11:36:30
Hello,

We've seen some problems with the implicit module activation for the gssapi
routines. According to gssapi.h:

[...]
 * @code
 *    globus_module_deactivate(GLOBUS_GSI_GSSAPI_MODULE)
 * @endcode
 * 
 * This function should be called once for each time Globus GSI GSSAPI
 * was activated.
 *
 * Note that it is not mandatory to call the above functions.
[...]

ie. it is not mandatory to call the globus_module_activate/deactive routines for
the GLOBUS_GSI_GSSAPI_MODULE when using the gssapi routines. Infact inspecting
the gssapi routines there are snippets like:

[... from gss_init_sec_context() ...]
    /* module activation if not already done by calling
     * globus_module_activate
     */
        
    globus_thread_once(
        &once_control,   
        (void (*)(void))globus_i_gsi_gssapi_module.activation_func);
[...]

However, we find some problems, apparenly because the implicit activation
doesn't go through the globus_module_activate() routine proper. For example:

A gssapi routine is used without explictly activating the GSSAPI_MODULE. Later a
globus module is explcitly activated, such as GLOBUS_GASS_COPY_MODULE and then
deactivated later. In this case globus raises an assertion, eg:

Assertion client_entry != GLOBUS_NULL failed in file globus_module.c at line 862

(depending on the situation it is also possible to run into more obsure errors,
when the modules are deactivated out of order - usualy appearing as double calls
to free())

If instead the earlier gssapi routines are wrapped up with a globus activate and
a globus deactivate call, a later gssapi routine called without explicit
activation will fail because the "once_control" will not trigger a second
implicit activation. Generaly the code will fail due to some uninitalised module.

I cann't see any way around this for us without it being addressed inside
globus; In the user code we can try to do all the GSSAPI activated/deactivated
explicitly, but if you take libraries from thrid parties it difficult to request
that the authors use the (de)activation methods when they only use gssapi.
(given that it's documented not to need them)

It would be very helpful if somebody could look into this.

(We have demonstrated this in globus 2.4, but from inspeciting the code I
believe the same problem to be in globus up to and including 3.2-rc2)

Many thanks,
David
------- Comment #1 From 2004-05-13 11:46:27 -------
Do you happen to have a test case for this problem?
------- Comment #2 From 2004-05-14 11:15:52 -------
Hi,

I've just made a quick test program. With this test I find that unless I answer
all the questions N, I get a crash or assertion.

You'll need a credential somewhere available -- as the routine is exercising
gssapi by acquiring and releasing a credential. If you get "Got gss error!" then
it couldn't find one.

Attached as 't.c' with a gcc command that should compile it in 't.sh'

David
------- Comment #3 From 2004-05-14 11:17:09 -------
Created an attachment (id=384) [details]
test snippit for gssapi

test prog for gssapi module activiation
------- Comment #4 From 2004-05-14 11:17:45 -------
Created an attachment (id=385) [details]
gcc snippit to compile t.c

gcc command line to compile t.c
------- Comment #5 From 2004-06-04 09:05:00 -------
Created an attachment (id=391) [details]
Patch for bug

The attached patch should fix the problem. It has one side effect though and
that is that deactivate_all will nullify the implicit activation, so calling
these routines after a deactivate_all without doing explicit activation will
fail.
------- Comment #6 From 2004-10-28 03:02:19 -------
Hi Sam,

> The attached patch should fix the problem. It has one side effect though and
> that is that deactivate_all will nullify the implicit activation, so calling
> these routines after a deactivate_all without doing explicit activation will
> fail.

Do you intend to rework this so that deactivate_all will not cause problems for
a subsequent use of GSSAPI_MODULE without explicit activation? Or should
developers now understand that the implicit activation is only valid in the case
where no ideactivate_all() is ever called?

Practicaly speaking, if a developer is providing a library that is assuming
implicit activation of the GSSAPI_MODULE it will constrain the user of the
library to not use deactivate_all() - and indeed the user of the library may not
know if the library is relying on the implicit activation or not. Therefore it
seems the only safe course at the moment, is to avoid deactivate_all()
alltogether. Do you agree?

Many thanks,
David
------- Comment #7 From 2004-10-28 09:58:44 -------
> Do you intend to rework this so that deactivate_all will not cause problems 
> for a subsequent use of GSSAPI_MODULE without explicit activation? Or should
> developers now understand that the implicit activation is only valid in the 
> case where no ideactivate_all() is ever called?
>
 
As I mentioned before: you can call deactivate_all(), you can just not expect to
be able to use gssapi calls after that.

> Practicaly speaking, if a developer is providing a library that is assuming
> implicit activation of the GSSAPI_MODULE it will constrain the user of the
> library to not use deactivate_all() - and indeed the user of the library may not
> know if the library is relying on the implicit activation or not. Therefore it
> seems the only safe course at the moment, is to avoid deactivate_all()
> alltogether. Do you agree?

I would argue that libraries that call deactivate_all() are broken in any case,
so yes I agree. The only thing that should ever call deactivate_all() is a
application.

/Sam
------- Comment #8 From 2004-10-28 10:12:36 -------
Hi Sam,

I'll repond to the second part of your last comment first:

> I would argue that libraries that call deactivate_all() are broken in any
> case, so yes I agree. The only thing that should ever call deactivate_all() 
> is a application.

My point is that an application cannot use deactivate_all(), if it ever expects
to subsequently use a library that may use gloubs gssapi. Hence:

> As I mentioned before: you can call deactivate_all(), you can just not expect
> to be able to use gssapi calls after that.

I think it would be more consistent to still be able to use gssapi calls after
deactivate_all(). Afterall, I would think that the point of allowing the
implicit activation is to allow programers to not worry about the globus module
symantics, if they are using only GSI.

Thanks,
David
------- Comment #9 From 2004-10-28 10:40:28 -------
Ah, but the problem you are describing only occurs when a application mixes
things. As far as I am concerned we only support two case

a) the app uses explicit globus module activation/deactivation - everything
should be fine, you can deactivate_all() as much as you want.
b) the app uses gsi without using module activation/deactivation - everything
should be fine

The only problem occurs in apps that try to mix the two cases and I don't think
we care to support that.

/Sam
------- Comment #10 From 2004-11-02 03:00:22 -------
Hello Sam,

Thanks for the clarification of globus' position.

Yours,
David