[
https://issues.apache.org/jira/browse/HADOOP-16167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16786943#comment-16786943
]
Allen Wittenauer commented on HADOOP-16167:
-------------------------------------------
bq. This technique is discouraged with the discovery of shellshock
vulnerability that trailing string can trigger unintended execution.
Citation needed. I've never seen the usage of indirects being discouraged
anywhere.
bq. One small nitpick, the patch may be reduced on reliance on indirection by
properly quote the condition check:
This isn't true, like, at all. If you look at hadoop_subcommand_opts, you'll
find this:
{code}
uvar="${uprogram}_${ucommand}_OPTS"
{code}
... which means uvar is always defined. This code:
{code}
if [[ -n ${!uvar} ]]; then
{code}
looks to see if ${uprogram_ucommand_OPTS} has a value. e.g.,
HDFS_NAMENODE_OPTS. Replacing that with
{code}
if [ -n "${uvar}" ]; then
{code}
Would just check if uvar has been set to something (it will be, every time,
guaranteed) and then do this operation:
{code}
HADOOP_OPTS="${HADOOP_OPTS} ${!uvar}"
{code}
.. which, if it hasn't been defined, cause a reference error. So this advice
is very very incorrect.
As to the patch,
a) It's incomplete since yarn (and I think MR?) does similar things.
b) It feels overly complicated. It'd probably be better to do
{code}
function hadoop_need_reexec
{
declare program=$1
declare command=$2
declare uvar
+ # don't process raw methods
+ if [[ ${command} =~ \. ]]; then
+ return 1
+ fi
# we've already been re-execed, bail
if [[ "${HADOOP_REEXECED_CMD}" = true ]]; then
return 1
fi
{code}
(similar code in hadoop_verify_user_perm, probably others)
As that will cover every case in one spot; the whole point of consolidating
this functionality.
> "hadoop CLASSFILE" prints error messages on Ubuntu 18
> -----------------------------------------------------
>
> Key: HADOOP-16167
> URL: https://issues.apache.org/jira/browse/HADOOP-16167
> Project: Hadoop Common
> Issue Type: Improvement
> Components: scripts
> Affects Versions: 3.2.0
> Reporter: Daniel Templeton
> Assignee: Daniel Templeton
> Priority: Major
> Attachments: HADOOP-16167.001.patch
>
>
> {noformat}
> # hadoop org.apache.hadoop.conf.Configuration
> /usr/lib/hadoop/bin/../lib/hadoop/libexec//hadoop-functions.sh: line 2366:
> HADOOP_ORG.APACHE.HADOOP.CONF.CONFIGURATION_USER: bad substitution
> /usr/lib/hadoop/bin/../lib/hadoop/libexec//hadoop-functions.sh: line 2331:
> HADOOP_ORG.APACHE.HADOOP.CONF.CONFIGURATION_USER: bad substitution
> /usr/lib/hadoop/bin/../lib/hadoop/libexec//hadoop-functions.sh: line 2426:
> HADOOP_ORG.APACHE.HADOOP.CONF.CONFIGURATION_OPTS: bad substitution
> {noformat}
> The issue is a regression in bash 4.4. See
> [here|http://savannah.gnu.org/support/?109649]. The extraneous output can
> break scripts that read the command output.
> According to [~aw]:
> {quote}Oh, I think I see the bug. HADOOP_SUBCMD (and equivalents in yarn,
> hdfs, etc) just needs some special handling when a custom method is being
> called. For example, there’s no point in checking to see if it should run
> with privileges, so just skip over that. Probably a few other places too.
> Relatively easy fix. 2 lines of code, maybe.{quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
