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

validate_cmd creates tmp file with inconsistent permissions

    Details

    • Template:
      PUP Bug Template
    • Team:
      Coremunity
    • Sprint:
      Platform Core KANBAN
    • Method Found:
      Needs Assessment
    • Release Notes:
      Bug Fix
    • Release Notes Summary:
      If there is a `validate_cmd` for a File resource, the command will be run with the temporary after the temporary file has had the final permissions set (on POSIX platforms).
    • QA Risk Assessment:
      Needs Assessment

      Description

      Puppet Version: 5.5.0
      Puppet Server Version: NA
      OS Name/Version: Linux & Mc OSX confirmed

      When the validate_cmd runs it creates a temporary file however the permissions it assigns to this temporary file are not related to the permissions defined on the file type object. 

      Desired Behaviour:

      The temporary file used when running the validate command should have the exact same permissions as the file resources it is trying to create.  e.g. 

      with a file type of

      file {'/tmp/test':
         owner => 'foo',
         group => 'bar',
         mode  => '0555',
         validate_cmd => 'test -x %'
      }

      the tmpe file created should have `foo:bar 0555` permissions

      Actual Behavior:

      I have observed the following behaviour.

      • tmp files are always created with permissions `0600`
      • if the file being managed does not exist the tmp file is owned by root
      • if the file being managed the tmp file uses has the same owner as the file being managed on disk

       
      the following runs a loop to detect the how the tmp file is created.  the tests use the folloing manifest file

      file {'/tmp/test/test':
        ensure => file,
        owner => 'jbond',
        group => 'jbond',
        content => 'foobar',
        validate_cmd => '/bin/false ',
      }
      

      output when `/tmp/test/test` doesn't exist

      root@dev:~# ls -la /tmp/test/
      total 8
      drwxr-xr-x  2 root root 4096 Jul  5 16:40 .
      drwxrwxrwt 11 root root 4096 Jul  5 16:41 ..
      root@dev01.l:~# while true ; do ls -l /tmp/test/ | grep test ; done
      -rw------- 1 root root 6 Jul  5 16:41 test20180705-24634-jluwct
      

      output when file exists with correct permissions

      root@dev01.l:~# ls -la /tmp/test/test
      -rw-r--r-- 1 jbond jbond 0 Jul  5 16:42 /tmp/test/test
      root@dev:~# while true ; do ls -l /tmp/test/ | grep test | egrep -v 'test$'; done
      -rw------- 1 jbond jbond 6 Jul  5 16:43 test20180705-5929-sdmjsa
       

      output when file exists with correct incorrect permissions

      root@dev~# chown nsd:nsd /tmp/test/test
      root@dev:~# ls -la !$
      ls -la /tmp/test/test
      -rw-r--r-- 1 nsd nsd 0 Jul  5 16:42 /tmp/test/test
      root@dev:~# while true ; do ls -l /tmp/test/ | grep test | egrep -v 'test$'; done
      -rw------- 1 nsd nsd 6 Jul  5 16:43 test20180705-22012-13alhap
      

      This causes problems when the validate command drops previlages or needs to run as a specific user.  An example of this is  using `/usr/lib/quagga/bgpd` to validate quagga files.  The command by default drops privileges to the quagga user before reading the config file.  if the file is owned by anything other then quagga then the validate command fails.  

       

      • note the bgpd command does take a user parameter so you can run the tests as the root user.  however bgpd still drops privileges to the root user and when it does so it does so without `CAP_DAV_OVERRIDE`.  meaning that even the root user can only validate files owned by root

       

       

        Attachments

          Activity

            People

            • Assignee:
              jacob.helwig Jacob Helwig
              Reporter:
              b4ldr john
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Zendesk Support