[
https://issues.apache.org/jira/browse/HADOOP-14636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16079254#comment-16079254
]
Allen Wittenauer commented on HADOOP-14636:
-------------------------------------------
{code}
${env.LD_LIBRARY_PATH}
{code}
... is a Configuration object-type setting, which means it is either coming
from the test code/config itself and/or Configuration can't deal with empty env
vars.
Three other points:
* This might be a nice, fat security hole. If it's treating that as empty,
then that gets translated to the current dir under normal shell semantics.....
which means it's generally trivial to exploit by placing a bad shared library.
* We apparently have LD_LIBRARY_PATH all over the place but not
DYLD_LIBRARY_PATH. This means anything using dyld (such as OS X) will have a
very different experience.
* I've been wondering for a while if we even need to set java.library.path if
we are already setting DY/LD_LIBRARY_PATH. Isn't one initialized from the
other anyway?
> TestKDiag failing intermittently on Jenkins/Yetus at login from keytab
> ----------------------------------------------------------------------
>
> Key: HADOOP-14636
> URL: https://issues.apache.org/jira/browse/HADOOP-14636
> Project: Hadoop Common
> Issue Type: Bug
> Components: security, test
> Affects Versions: 3.0.0-beta1
> Environment: {code}
> user.name = "jenkins"
> java.version = "1.8.0_131"
> java.security.krb5.conf =
> "/testptch/hadoop/hadoop-common-project/hadoop-common/target/1499472499650/krb5.conf"
> kdc.resource.dir = "src/test/resources/kdc"
> hadoop.kerberos.kinit.command = "kinit"
> hadoop.security.authentication = "KERBEROS"
> hadoop.security.authorization = "false"
> hadoop.kerberos.min.seconds.before.relogin = "60"
> hadoop.security.dns.interface = "(unset)"
> hadoop.security.dns.nameserver = "(unset)"
> hadoop.rpc.protection = "authentication"
> hadoop.security.saslproperties.resolver.class = "(unset)"
> hadoop.security.crypto.codec.classes = "(unset)"
> hadoop.security.group.mapping =
> "org.apache.hadoop.security.JniBasedUnixGroupsMappingWithFallback"
> hadoop.security.impersonation.provider.class = "(unset)"
> dfs.data.transfer.protection = "(unset)"
> dfs.data.transfer.saslproperties.resolver.class = "(unset)"
> 2017-07-08 00:08:20,381 WARN security.KDiag (KDiag.java:execute(365)) - The
> default cluster security is insecure
> {code}
> Reporter: Steve Loughran
> Priority: Minor
> Attachments: output.txt
>
>
> The test {{TestKDiag}} is failing intermittently on Yetus builds,
> {code}
> org.apache.hadoop.security.KerberosAuthException: Login failure for user:
> [email protected] from keytab
> /testptch/hadoop/hadoop-common-project/hadoop-common/target/keytab
> javax.security.auth.login.LoginException: Unable to obtain password from user
> {code}
> The tests that fail are all trying to log in using a keytab just created, the
> JVM isn't having any of it.
> Possible causes? I can think of a few to start with
> # keytab generation
> # keytab path parameter wrong
> # JVM isn't doing the login
> # some race condition
> # Host OS
> # Other environment issues (clock, network...)
> There's no recent changes in the kdiag or UGI code.
> The failure is intermittent, not surfacing for me (others?) locally, which
> which could point at: JVM, host OS, race condition, other env issues.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
