[PUP-5915] exec resources fail unless cwd is readable Created: 2016/02/17 Updated: 2019/11/18 Resolved: 2019/10/21
|Affects Version/s:||PUP 4.3.2|
|Fix Version/s:||PUP 5.5.18, PUP 6.4.5, PUP 6.11.0|
|Reporter:||James Ralston||Assignee:||Josh Cooper|
|Remaining Estimate:||Not Specified|
|Time Spent:||Not Specified|
|Original Estimate:||Not Specified|
|Template:||PUP Bug Template customfield_10700 117135|
|Epic Link:||Execution API|
|Sprint:||Platform Core KANBAN|
|Release Notes:||Bug Fix|
|Release Notes Summary:||Previously if the `cwd` parameter was not specified, puppet would change its working directory to the current working directory, which was redundant and could fail if the current working directory was not accessible. Now wxec resources only change the current working directory if the `cwd` parameter is specified in a manifest.|
The exec() resource always attempts to perform a chdir() to the current working directory (cwd). This is true regardless of the value of the cwd parameter.
If the cwd isn't accessible by the user running Puppet, Puppet will fail to apply the exec() resource. This is true regardless of whether the command being executed actually requires the cwd to be readable.
If the cwd is accessible, the exec will succeed:
You may be tempted to respond: "Why does this matter? It's almost never useful to run Puppet as a non-root user, and the root user has implicit access to all files and directories."
The problem is that this is not true.
At our site, we are deploying NFSv4 user home directories, where home directories are mounted from an NFSv4 server with sec=krb5p (that is, with Kerberos security). In such a scenario, the root user always and implicit possesses host/hostname@DOMAIN credentials, and nothing more.
User home directories are private (mode 0700) by default. Effectively, this means that the root user is unable to chdir() to a user's home directory, or any subdirectory thereof.
As we began to deploy NFSv4 user home directories, developers who run sudo puppet agent --test from the command line began reporting Puppet failures. Investigating the problems let us to discover the exec resource's behavior of always attempting to chdir() to the cwd, regardless of what the cwd parameter is set to (or whether it's defined at all).
Our developers get hit by this because they are typically sitting in their (NFSv4-based) home directory when they attempt to run sudo puppet agent --test.
I would argue that the exec resource should behave this way:
The current behavior of the exec resource is at best extremely non-intuitive and at worst outright incorrect, even if it only causes problems when specific (and uncommon) conditions are met (i.e., root not having implicit access to the cwd).
|Comment by James Ralston [ 2016/02/17 ]|
Also, unless I'm missing something, the fix is pretty simple. Here's a quick diff (ignoring whitespace changes, so that it's easier to read):
I've tested this locally, and it seems to work.
This does move the chdir() call outside of the begin/rescue/end block, though. Does the chdir() call by itself warrant its own begin/rescue/end block?
Anyway, if this looks good, I'll be happy to submit a merge request.
|Comment by Henrik Lindberg [ 2017/05/15 ]|
James Ralston did you get around to making a PR?
|Comment by Doug Penner [ 2018/01/29 ]|
I can confirm that the problem also exists in puppet 5.3.3.
If we are in our home folders on a system with root-squash, we get the same error as James whether we set a cwd or not.
|Comment by James Ralston [ 2018/03/02 ]|
My first attempt at solving the problem was incorrect, which is why I never submitted a PR. But this is still biting us, so I'll take another crack at it.
|Comment by Adam Winberg [ 2018/08/14 ]|
This is in effect the same as
|Comment by James Ralston [ 2019/09/04 ]|
The issue with the exec resource failing due to receiving EACCES when attempting to call chdir() to the cwd was resolved
But the root cause of this issue—that it is never safe to call chdir() except in a child process—is not completely resolved. See PUP-9997 for details.
(Puppet 5.5.7 was the first version to contain the fix.)
|Comment by James Ralston [ 2019/10/08 ]|
I was incorrect. This is not actually fixed.
Moving the chdir() call in Puppet::Util::Execution.execute() into the child solves the case where Puppet is running in a directory that is inaccessible, but applies an exec resource that specifies a different directory for the cwd parameter. Before, Puppet would chdir() in the parent process, and would therefore fail to chdir() back to the old cwd after applying the exec resource.
But the exec resource itself (still) implicitly defaults the cwd parameter to the cwd if the cwd parameter was not provided for the exec resource in question. And in the case where Puppet's cwd is inaccessible, this will cause all Puppet exec() resources to fail.
So: I assert that defaulting the cwd parameter to the cwd of the Puppet process is wrong. If the user does not supply a cwd parameter to the exec resource in question, Puppet must assume that the user does not want Puppet to attempt to chdir() to any directory. Assuming that the user wants Puppet to chdir() to the cwd is an erroneous assumption, as 1) this is not what the user specified, and 2) it's nonsensical, as even if the chdir() call succeeds, Puppet has not actually changed the cwd.
I think the only thing required is removing this line from lib/puppet/provider/exec.rb:
This is because, from my read, Puppet::Util::Execution.execute() will do the correct thing if the cwd parameter is unspecified:
|Comment by Josh Cooper [ 2019/10/15 ]|
|Comment by Josh Cooper [ 2019/10/21 ]|
Passed CI in dc81e4e117