On 02/08/2013 10:24 PM, Valerie (Yu-Ching) Peng wrote:
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.
Agreed.
-Chris.
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.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
