Hadoop SDK: 当静态 LoginUser 被其他组件覆盖时, Kerberos AP-REQ 会间歇性失败
作者: LiuZheng-Z创建于 2026年9月4日更新于 2026年9月4日
标签kind/bug
发生了什么事#
JuiceFileSystemImpl#buildingAuthCreditience'和io.juicefs.kerberos.KerberosUtil#genApReq'均从`用户组信息.getLoginUser ()'获得认证本能。
" UserGroup Information.loginUser Ref " 是UGI级的一个 " static " 领域。 在正常的部署中,类被AppClassLoader装入一次,因此这个静态的引用在整个JVM中共享. ** 同一JVM中的任何组件都可以覆盖**——例如通过UserGroup Information.loginUser FromSubject(新主体())'——用一个没有KerberosTicket'的主题取代“真正的”登录用户。
当JuiceFS Hadoop SDK后来在JVM中被引用时:
Get LoginUser (.). has Kerberos Creditis ()' 仍然返回ret' (因为auth Method'只是User'主机上的电荷,在主题内容变化时没有重设),因此建立证书 ' 路线进入Kerberos分支,并称KerberosUtil.genApReq'。- 在
genApReq'、loginUser.doAs(.)'内,在一个没有TGT的主题下执行,因此,JGSS`Krb5 Initience.get。 exception:没有提供有效的证书( 机能级别: 找不到 Kerberos tgt) 。
堆叠跟踪( 缩写) :
java.lang.reflect. Unlated Throwable Exception at. KerberosUtil.lambda$genApReq$0 (KerberosUtil.java::.) at User Group Information.doAs (.) at io.juicefs.kerberosUtil.genApReq (.) at io.juicefsfs. JuiceFileSystempl.building AuthCreditive (.) 页面存档备份,存于互联网档案馆,存于互联网档案馆. 由:GSS例外:没有提供有效的证书(机能级别:在 sun.security.jgs.krb5.Krb5 InitCreditive.getInstance (.) 在 sun.security.jgs.GSSContext Impl.initSecContext (.) )□再现.
一个非常常见的触发器是通过“loginUserFromKeytabAnd ReturnUGI”登录自己的主机,然后用“catalogUgi.doAs(.)”包接下游的所有工作。 私人UGI保留在目前的获取控制ControlContext'(可通过getCurrentUser ()'观察)中,但从未成为全球登录用户——因此依赖`get LoginUser ()'取出错误的身份。
最小复制器 :
java / (1) JVM中的其他部分已经安装了一个没有主题的UGI // 作为全局登录用户. 任何名为登录用户从Subject () 的操作都会这样做 。 用户Group Information.loginUser FromSubject(新javax.security.auth.Subject ()); //得到LoginUser () 现在返回一个UGI,其对象没有Kerberos Ticket, //但认证方法仍然是KERBEROS, //所以Kerberos Creditis() 已经从较早的登录中存在谎言并返回了真.
// (2)应用程序进行自己的私家Kerberos登录并驱动所有工作 // 通过 doAs——标准And ReturnUGI + doAs模式. 用户组信息目录Ugi = 用户组信息.loginUser From Keytaband ReturnUGI ("hadoop/host@REALM","/path/to/host.keytab") ;
catalogUgi.doAs ((PrivicedException Action ()) () - > { FileSystem fs = FileSystem.get (新URI ("jfs://vol1/")), conf; fs.listStatus (新路径 ("/")); /← 扔出GSSException:未提供有效证书
. . . . . . .内容来源: juicedata/juicefs