Does -Djava.security.debug=logincontext show anything? This is the formal way to debug JAAS.
Also, you can put debug=true in your Krb5LoginModule config entry and see what's happening, and there is always -Dsun.security.krb5.debug=true to show kerberos related debug info. --Max > On Dec 11, 2018, at 4:57 PM, Wenxiang <wenxiang....@foxmail.com> wrote: > > Hi everyone, > > I was using Hadoop command line interface to access HDFS with a non-root > user. After successfully running kinit, Hadoop FsShell fails with > GSSException: No valid credentials provided (Mechanism level: Failed to find > any Kerberos tgt). After using a subclassed Krb5LoginModule to print out > necessary debug info, I found that the login module's login method failed > because permissions of some jars in classpath are not properly set and > process doesn't have read permissions to them. A > java.lang.ExceptionInInitializerError is thrown. Because the login method is > invoked via reflection in LoginContext, the ExceptionInInitializerError is > wrapped in an InvocationTargetException and is caught in LoginContext#invoke. > Since this Kerberos login module is optional and the following login module > logins successfully, the exception is logged nowhere and the > ExceptionInInitializerError thrown from deep in the call stack is completely > swallowed silently, making debugging this problem extremely hard. > > My point here is that codes in LoginModule are not supposed to catch and > process java.lang.Error, and I am confused by the way that reflection method > invocation in LoginContext#invoke just swallows silently errors thrown by the > method invoked. When an Error occurs, it means something really bad happened. > I think LoginContext#invoke should either propagate errors to upper codes, or > at least log such events. > > This error-swallowing behavior is consistent from jdk 7 to jdk 11. I would > like to have some expert comments on this to help me understand this design. > Thanks. > > Wenxiang Qiu
