|
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.
An example:
$ cd /tmp
|
$ mkdir test
|
$ cd test
|
$ chmod 0000 .
|
|
$ puppet apply -e 'exec { "/bin/pwd": logoutput => true }'
|
Notice: Compiled catalog for myhost.example.org in environment production in 0.05 seconds
|
Error: Permission denied @ dir_chdir - /tmp/test
|
Error: /Stage[main]/Main/Exec[/bin/pwd]/returns: change from notrun to 0 failed: Permission denied @ dir_chdir - /tmp/test
|
Notice: Applied catalog in 0.04 seconds
|
|
$ puppet apply -e 'exec { "/bin/pwd": logoutput => true, cwd => "/" }'
|
Notice: Compiled catalog for myhost.example.org in environment production in 0.06 seconds
|
Error: Permission denied @ dir_chdir - /tmp/test
|
Error: /Stage[main]/Main/Exec[/bin/pwd]/returns: change from notrun to 0 failed: Permission denied @ dir_chdir - /tmp/test
|
Notice: Applied catalog in 0.05 seconds
|
If the cwd is accessible, the exec will succeed:
$ chmod 0755 .
|
|
$ puppet apply -e 'exec { "/bin/pwd": logoutput => true }'
|
Notice: Compiled catalog for myhost.example.org in environment production in 0.05 seconds
|
Notice: /Stage[main]/Main/Exec[/bin/pwd]/returns: /tmp/test
|
Notice: /Stage[main]/Main/Exec[/bin/pwd]/returns: executed successfully
|
Notice: Applied catalog in 0.05 seconds
|
|
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:
-
If the cwd parameter is defined, the exec resource attempts to chdir() to that directory, and only that directory.
-
If the cwd parameter is undefined, the exec resource should not call chdir() at all.
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).
Thoughts?
|
