[
https://issues.apache.org/jira/browse/HADOOP-15722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16628961#comment-16628961
]
Daryn Sharp commented on HADOOP-15722:
--------------------------------------
{quote}But only admin will be configuring the cluster,so he will be aware
,hence allowing system properties should be fine I feel.
{quote}
That's only true if the user code is never allowed to access the config object
– which in practice is likely never the case. Otherwise user code may simply
set a key with a reference to sensitive property and then get it and the
property is resolved.
Deciding what and when property resolution is "safe" is a rabbit hole I'd
prefer to avoid descending if possible.
This seems like a trivial problem to solve. Instead of smashing the system
property (which is the race condition I described), why not:
# set the user.name config key to remove the property fallback, or
# replace the user.name property in hive.exec.scratchdir with a static value?
If this is only current concrete use case, which can be trivially resolved, I
don't feel this should be a blocker.
> regression: Hadoop 2.7.7 release breaks spark submit
> ----------------------------------------------------
>
> Key: HADOOP-15722
> URL: https://issues.apache.org/jira/browse/HADOOP-15722
> Project: Hadoop Common
> Issue Type: Bug
> Components: build, conf, security
> Affects Versions: 2.7.7
> Reporter: Steve Loughran
> Priority: Major
>
> SPARK-25330 highlights that upgrading spark to hadoop 2.7.7 is causing a
> regression in client setup, with things only working when
> {{Configuration.getRestrictParserDefault(Object resource)}} = false.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
