Uploaded image for project: 'Puppet'
  1. Puppet
  2. PUP-5915

exec resources fail unless cwd is readable

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Normal
    • Resolution: Fixed
    • Affects Version/s: PUP 4.3.2
    • Fix Version/s: PUP 5.5.18, PUP 6.4.5, PUP 6.11.0
    • Component/s: None
    • Labels:
      None
    • Release Notes:
      Bug Fix
    • Release Notes Summary:
      Hide
      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.
      Show
      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.

      Description

      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:

      1. If the cwd parameter is defined, the exec resource attempts to chdir() to that directory, and only that directory.
      2. 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?

        Attachments

          Issue Links

            Activity

              jsd-sla-details-panel

                People

                • Assignee:
                  josh Josh Cooper
                  Reporter:
                  ralston James Ralston
                • Votes:
                  4 Vote for this issue
                  Watchers:
                  6 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved:

                    Zendesk Support