Valerie,
C is not distinguish between 0 and NULL.
In GSS case GSS_C_NO_CHANNEL_BINDINGS (expanded to 0) means that client
and server agreed that basic context is OK.
So return of GSS_C_NO_CHANNEL_BINDINGS(0) in OOM case could lead to
security issue if upper level doesn't check for exception.
I have no good and cheap solution for this problem.
-Dmitry
On 2013-02-09 00:19, Valerie (Yu-Ching) Peng wrote:
> I think it's ok just to use NULL. An OOM is pretty self-explanatory.
> Most if not all invocations that I recall seeing simply use NULL.
> Valerie
>
> On 02/08/13 12:00, John Zavgren wrote:
>> All:
>>
>> I assume that anytime a "JNI" procedure in the native code experiences
>> an OOM (Out Of Memory) error, then it should throw an exception, by
>> executing: JNU_ThrowOutOfMemoryError(env, NULL);
>>
>> src/share/native/sun/security/jgss/wrapper/GSSLibStub.c
>> src/share/native/sun/security/jgss/wrapper/NativeUtil.c
>> src/share/native/sun/security/smartcardio/pcsc.c
>> src/solaris/native/com/sun/security/auth/module/Solaris.c
>> src/solaris/native/com/sun/security/auth/module/Unix.c
>>
>> If so, what messages, if any, should I pass as their second argument,
>> instead of NULL?
>>
>>
>>
>> Thanks!
>> John
>> ----- Original Message -----
>> From: dmitry.samers...@oracle.com
>> To: john.zavg...@oracle.com
>> Cc: security-dev@openjdk.java.net
>> Sent: Friday, February 8, 2013 1:35:41 PM GMT -05:00 US/Canada Eastern
>> Subject: Re: RFR: JDK-8007607
>>
>> John,
>>
>>> Ideas?
>> It's a JNI so just throw OOM.
>>
>> -Dmitry
>>
>>
>> On 2013-02-08 21:38, John Zavgren wrote:
>>> Although I agree that the name: "GSS_C_NO_CHANNEL_BINDINGS" is
>>> misleading,
>>> I can't identify anything else that seems more appropriate.
>>>
>>> The header file:
>>> /jdk8-tl/jdk/src/share/native/sun/security/jgss/wrapper/gssapi.h defines
>>> GSS_C_NO_CHANNEL_BINDINGS as follows:
>>> #define GSS_C_NO_CHANNEL_BINDINGS ((gss_channel_bindings_t) 0)
>>>
>>> The symbol matches the prototype of the function:
>>>
>>> */*
>>> * Utility routine which creates a gss_channel_bindings_t structure
>>> * using the specified org.ietf.jgss.ChannelBinding object.
>>> */
>>> gss_channel_bindings_t getGSSCB(JNIEnv *env, jobject jcb) {
>>> gss_channel_bindings_t cb;
>>> jobject jinetAddr;
>>> jbyteArray value;
>>>
>>> if (jcb == NULL) {
>>> return GSS_C_NO_CHANNEL_BINDINGS;
>>> }
>>> cb = malloc(sizeof(struct gss_channel_bindings_struct));
>>>
>>> if(cb == NULL)
>>> return GSS_C_NO_CHANNEL_BINDINGS;*
>>>
>>> There doesn't appear to be anything in our set of options that is more
>>> suggestive of a memory allocation failure and the symbol:
>>> GSS_C_NO_CHANNEL_BINDINGS seems to be logically correct.
>>>
>>> Ideas?
>>>
>>> On 02/06/2013 04:57 AM, Dmitry Samersoff wrote:
>>>> John,
>>>>
>>>> Not sure GSS_C_NO_CHANNEL_BINDINGS; is correct return value for this
>>>> case.
>>>>
>>>> I'm second to Valerie - it's better to throw OOM
>>>>
>>>> -Dmitry
>>>>
>>>>
>>>> On 2013-02-06 03:44, John Zavgren wrote:
>>>>> Greetings:
>>>>>
>>>>> I modified the native code to eliminate potential memory loss and
>>>>> crashes by checking the return values of malloc() and realloc() calls.
>>>>>
>>>>> The webrev image of these changes is visible at:
>>>>> http://cr.openjdk.java.net/~jzavgren/8007607/webrev.01/
>>>>>
>>>>> Thanks!
>>>>> John Zavgren
>>>>>
>>>
>>> --
>>> John Zavgren
>>> john.zavg...@oracle.com
>>> 603-821-0904
>>> US-Burlington-MA
>>>
>>
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* Give Rabbit time, and he'll always get the answer
