The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com

Bug #5495

Exec resource searches CWD when testing file attributes of executables

Added by Luke Bigum almost 4 years ago. Updated over 1 year ago.

Status:ClosedStart date:12/10/2010
Priority:HighDue date:
Assignee:Nick Lewis% Done:

0%

Category:exec
Target version:2.7.4
Affected Puppet version:2.6.3 Branch:
Keywords: customer

We've Moved!

Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com

This issue is currently not available for export. If you are experiencing the issue described below, please file a new ticket in JIRA. Once a new ticket has been created, please add a link to it that points back to this Redmine ticket.


Description

I’ve noticed a problem with Exec resources that use an explicit or global default path seem to search the current working directory when testing the attributes on executable commands as part of ‘unless’, ‘onlyif’ or ‘command’ parameters where the binary is an unqualified (eg: “grep” vs “/bin/grep”). If the current working directory contains a file of the same name as what is to be executed in the Puppet manifest, then it may cause the Ruby sanity tests in type/exec.rb to fail.

See the following terminal log for a demonstration:

[root@host ~]# pwd
/root
[root@host ~]# cat test.pp
exec { "test Exec":
path => "/usr/sbin:/usr/bin:/sbin:/bin",
command => "echo Woof",
onlyif => "grep localhost /etc/hosts",
}
[root@host ~]# puppet apply test.pp
notice: /Stage[main]//Exec[test Exec]/returns: executed successfully
[root@host ~]# touch grep
[root@host ~]# puppet apply test.pp
err: /Stage[main]//Exec[test Exec]: Could not evaluate: 'grep' is not executable
[root@host ~]# rm grep
rm: remove regular empty file `grep'? y
[root@host ~]# touch echo
[root@host ~]# puppet apply test.pp
err: /Stage[main]//Exec[test Exec]/returns: change from notrun to 0 failed: 'echo' is not executable
[root@host ~]# rm echo
rm: remove regular empty file `echo'? y
[root@host ~]# puppet apply test.pp
notice: /Stage[main]//Exec[test Exec]/returns: executed successfully

From what I can tell this is not a security issue though. I’ve tried embedding a shell script of the same name as the binary in the CWD but it looks like it’s probably only the Ruby FileTest that has the problem, not the actual execution of binaries:

[root@host ~]# pwd
/root
[root@host ~]# cat grep
#!/bin/bash
touch Done_bad_stuff
[root@host ~]# cat test.pp
exec { "test Exec":
path => "/usr/sbin:/usr/bin:/sbin:/bin",
command => "echo Woof",
onlyif => "grep localhost /etc/hosts",
}
[root@host ~]# puppet apply test.pp
notice: /Stage[main]//Exec[test Exec]/returns: executed successfully
[root@host ~]# ls -ld Done_bad_stuff
ls: Done_bad_stuff: No such file or directory
[root@host ~]#

History

#1 Updated by Luke Bigum almost 4 years ago

Sorry, as usual forgot to include necessary OS information:

[root@host ~]# puppet --version
2.6.3
[root@host ~]# ruby --version
ruby 1.8.5 (2006-08-25) [x86_64-linux]
[root@host ~]# rpm -q puppet
puppet-2.6.3-1
puppet-2.6.3-1
[root@host ~]# rpm -q ruby
ruby-1.8.5-5.el5_4.8
[root@host ~]# cat /etc/redhat-release
CentOS release 5.4 (Final)
[root@host ~]# uname -a
Linux host.localdomain 2.6.18-164.15.1.el5 #1 SMP Wed Mar 17 11:30:06 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux

#2 Updated by Nigel Kersten almost 4 years ago

  • Status changed from Unreviewed to Accepted

#3 Updated by Jason Koppe over 3 years ago

We ran into this today because the CWD had a plain text file named test. We’re running CentOS 5.5 with puppet-2.6.7 and ruby-1.8.5.

#4 Updated by James Turnbull over 3 years ago

  • Status changed from Accepted to Needs Decision
  • Assignee set to Nigel Kersten

Nigel – see Support URL addition.

#5 Updated by Nigel Kersten over 3 years ago

  • Status changed from Needs Decision to Accepted
  • Assignee deleted (Nigel Kersten)
  • Priority changed from Normal to High
  • Target version set to 2.6.x

#6 Updated by Clay Caviness about 3 years ago

This would allow a user to fairly easily subvert puppet execs by simply creating a few non-executable files. Any movement here? It still looks like an issue in 2.7.x.

#7 Updated by Matt Robinson about 3 years ago

  • Assignee set to Nick Lewis
  • Target version changed from 2.6.x to 2.7.x

This is definitely buggy, and I was going to fix it when I found out Nick was working in the same area of code in order to get exec working on windows, so I’m assigning this to him.

#8 Updated by Nick Lewis about 3 years ago

  • Status changed from Accepted to Merged - Pending Release

A fix for this has been merged to 2.7.x in commit:1049458461b5ec5e1e48ad0244d63eb24626b09d, along with some refactoring to remove some dead Windows-specific code.

If the command path specified is absolute, we will now individually check that it exists, is a file, and is executable, and raise exceptions appropriately. If it’s relative, we will search for it in the specified path, and raise if no executable file is found. And we won’t ever consider file paths relative to the cwd, even if the command is specified with a relative path.

#9 Updated by James Turnbull about 3 years ago

  • Target version changed from 2.7.x to 2.7.4

#10 Updated by Matthaus Owens about 3 years ago

  • Status changed from Merged - Pending Release to Closed

Released in 2.7.4rc1

#11 Updated by Charlie Sharpsteen over 1 year ago

  • Keywords set to customer

Also available in: Atom PDF