I see. I am not sure we can fail here because historically we don't differentiate between a "system" failure and an "application" failure. Although the methods in LoginModule specify a LoginException, if another exception is thrown, we now treat it as a normal login error.
Maybe we can add more debug info. Do you have a suggested fix? I assume you see the "OPTIONAL failure" word but you'd like something like a stack trace? Thanks, Max > On Dec 25, 2018, at 3:26 PM, Vincent <wenxiang....@foxmail.com> wrote: > > 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 >
