Stopping an interface that is configured by dhcpcd causes the error: Reproducible: Always Steps to Reproduce: 1. rc-service net.eth0 stop Actual Results: * Stopping dhcpcd on eth0 ... dhcpcd: invalid option -- ' ' usage: dhcpcd [-146ABbDdEGgHJKLMNPpqTV] Expected Results: * Stopping dhcpcd on eth0 ... sending signal TERM to pid 12345 waiting for pid 12345 to exit Adding 'eval' to run dhcpcd in dhcpcd_stop() ( just like in dhcpcd_start() ) fixes the issue.
Created attachment 862609 [details, diff] Proposed patch
Thanks for the patch. I don't think this is a good pretext for using eval, because it introduces yet another opportunity for a configuration file to perform arbitrary code injection. The questionable use of eval is pervasive in many Gentoo projects but, still, we can try to make the situation better rather than worse. Please try the following method. printf '%s %s' "${args}" "${IFACE}" | xargs -E '' dhcpcd -k
(In reply to Kerin Millar from comment #2) > Thanks for the patch. I don't think this is a good pretext for using eval, > because it introduces yet another opportunity for a configuration file to > perform arbitrary code injection. The questionable use of eval is pervasive > in many Gentoo projects but, still, we can try to make the situation better > rather than worse. Please try the following method. > > printf '%s %s' "${args}" "${IFACE}" | xargs -E '' dhcpcd -k eval is used to run dhcpcd in the same file in dhcpcd_start() function. Why not just run dhcpcd with parameters without quotes (and without eval), e.g.: dhcpcd -k ${args} ${IFACE} ?
(In reply to drserge from comment #3) > (In reply to Kerin Millar from comment #2) > > Thanks for the patch. I don't think this is a good pretext for using eval, > > because it introduces yet another opportunity for a configuration file to > > perform arbitrary code injection. The questionable use of eval is pervasive > > in many Gentoo projects but, still, we can try to make the situation better > > rather than worse. Please try the following method. > > > > printf '%s %s' "${args}" "${IFACE}" | xargs -E '' dhcpcd -k > > eval is used to run dhcpcd in the same file in dhcpcd_start() function. I understand. But we can change it. > > Why not just run dhcpcd with parameters without quotes (and without eval), > e.g.: > dhcpcd -k ${args} ${IFACE} Because it permits pathname expansion and makes it impossible to express arguments that contain whitespace. Take a step back and consider the over-arching problem, which is essentially this: https://mywiki.wooledge.org/BashFAQ/050. Unlike bash, the Shell Command Language does not afford the programmer the luxury of using arrays. Time and time again, script writers work around this dangerously (using eval) and/or incorrectly (relying on word splitting without any certainty as to the value of IFS, while also neglecting to disable pathname expansion). Said writers commonly ignore the fact that the position parameter list can sometimes be used to approximate the properties of an array that are useful. Projects such as netfirc and openrc are the living embodiment of this folly [*]. Now, there is a saying in the #bash IRC channel that Sturgeon (as in Sturgeon's law) was an optimist. However, just because the majority of scripts in the wild are ill-conceived and poorly written, it does not mean that we should simply tolerate it and not attempt to do better whenever the opportunity arises. That is my contention. I consider it to be a paradox, because xargs(1) can be used portably (assuming the presence of XSI features) to implement what such projects are effectively crying out for, which is to implement shell-like parsing of arguments that have been jammed into a single string in a predictable, uniform fashion. Consider the following example. $ command_args='--path "/foo/bar baz/*" --pattern *' $ printf %s "$command_args" | xargs -E '' printf '[%s] '; echo [--path] [/foo/bar baz/*] [--pattern] [*] Can one accomplish this by merely expanding $command_args without quotes? No. Also note: - arbitrary code execution is impossible - pathname expansion is impossible (no need to fiddle with set -e and set +e) - the behaviour cannot be influenced by the effective value of IFS - it becomes possible to express arguments that contain whitespace In the overwhelming majority of cases, all of these characteristics may be considered desirable for the use case of parsing arbitrary arguments from scripts that are masquerading as configuration files and which can only be processed by sh(1), as opposed to a shell that is capable of supporting arrays. [*] https://bugs.gentoo.org/833087#c3
Correction: set -f and set +f (not -e and +e).
Created attachment 862726 [details, diff] Patch based on suggestion of Kerin Millar (with small readability cleanup)
Thanks for the revised patch. Other than the accidental inclusion of a trailing dot for "return 0", it looks good. Not that it pertains to this bug but the metric handling could also be simplified. The last -m option wins, so the (buggy) case " ${args} " code is unnecessary. In fact, I examined the script in full yesterday and rectified several issues of this kind. Just a little more testing is required here before I feel confident in volunteering a patch.
Any update on this? At least the attached patch seems to fix the issue for now.
This issue only happens when additional dhcpcd flags are provided in /etc/conf.d/net, e.g. dhcpcd_eth0="--timeout 40 --noipv4ll". It is still happening with net-misc/netifrc-0.7.5. Either of the provided patches fix the issue for me. In the interest of reducing the pain for users, maybe the eval-based patch is easier to review and could be applied first? Then the refactoring to remove the use of eval everywhere could be applied in a second step, as time allows. (Also, out of curiosity, why the -E '' in the suggested xargs invocation? Isn't that the default?)
(In reply to Remy Blank from comment #9) > (Also, out of curiosity, why the -E '' in the suggested xargs invocation? > Isn't that the default?) I have no further interest in this issue but this question deserves an answer. POSIX promises nothing in the absence of -E. "If -E is not specified, it is unspecified whether the logical end-of-file string is the <underscore> character ( '_' ) or the end-of-file string capability is disabled."
