Hi Max,
Thanks for your reply. Sorry I didn't mention it in my precedent mail, but I'm quite familiar with the usual debug process with JAAS and Krb5. Turning on these 3 debug switches was the first thing I went for when the problem occurred. But this time these didn't really help. That's why I wrote and used a new Krb5LoginModule to catch all Throwables and figured out the problem. The trouble here is that the problem is caused by wrong file permissions on some jar files used by Krb5LoginModule and thus an Error is thrown from deep down the call stack. It's not caught in Krb5LoginModule (it shouldn't) so debug logs turned on by debug=true and -Dsun.security.krb5.debug=true show nothing useful. When the Error is caught by LoginContext's invoke() (the Error is now wrapped in an InvocationTargetException by java reflection), LoginContext logs a failed optional login: [LoginContext]: login OPTIONAL failure And that's all. So the crucial problem is completely hidden. I don't think we should blame Hadoop for setting Krb5LoginModule as optional because it wants to fallback to simple authentication when krb5 fails. Besides, Krb5LoginModule and other Krb5 related modules do their best to provide debug info on Kerberos matters. But if problem is caused by external errors such as wrong file permissions, it seems to be impossible to locate it without rewriting some code. ------------------ Original ------------------ From: "Weijun Wang"<weijun.w...@oracle.com>; Date: Tue, Dec 11, 2018 05:55 PM To: "Vincent"<wenxiang....@foxmail.com>; Cc: "security-dev@openjdk.java.net"<security-dev@openjdk.java.net>; Subject: Re: java.lang.Error is swallowed by LoginContext#invoke 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
