RFR: JDK-8007607

[Valerie (Yu-Ching) Peng]

The NULL in my earlier email is about the second argument for the OOM 
error and not about the return code/value. As long as an OOM is thrown, 
the return code/value won't be used. Since we must return a value per 
JNI syntax even when OOM has been thrown, maybe we can just return -1, 
or 0, or NULL. I don't think it really matters.

Valerie

On 02/08/13 13:47, Dmitry Samersoff wrote:
> 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.samersoff at oracle.com
>>> To: john.zavgren at oracle.com
>>> Cc: security-dev at 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.zavgren at oracle.com
>>>> 603-821-0904
>>>> US-Burlington-MA
>>>>
>