Bug #5013
Facter assumes path that isn't there always
| Status: | Accepted | Start date: | 10/15/2010 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | - | % Done: | 0% | |
| Category: | interface | |||
| Target version: | - | |||
| Keywords: | Affected Facter version: | |||
| Branch: | ||||
Description
Related Bugs: 1901, 1745 and commit: Revision 051c8437
Facter when running in stand-alone mode, (not in the context of puppet) seems to rely on the user environment variables to resolve facts, specifically when running Facter::Util::Resolution.exec (see virtual.rb for an example, but not the only one).
Here is a simple test case. I knew in this case that this was on VMware.
/sbin/lspci | grep -i vmware |wc -l cat /etc/redhat-release facter --version export PATH=/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin facter virtual export PATH=/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin facter virtual
Output from this test case:
[root@sbox01 ~]# /sbin/lspci | grep -i vmware |wc -l #just to show it is indeed vmware 35 [root@sbox01 ~]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 5.5 (Tikanga) [root@sbox01 ~]# facter --version 1.5.8 [root@sbox01 ~]# export PATH=/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin [root@sbox01 ~]# facter virtual **vmware** [root@sbox01 ~]# export PATH=/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin [root@sbox01 ~]# facter virtual **physical**
This is problematic, as some of my privileged users run facter in scripts, however the facts do not resolve correctly if they don’t have /sbin and/or /usr/sbin in their PATH.
I would have submitted a patch, but this seems to be more of a design decision than a code fix, especially after seeing already closed issues related to this topic.
I see this as a bug, and a fairly easy to fix, but serious bug.
Related issues
History
#1
Updated by Michael Stahnke over 2 years ago
Arg formatting.
Test Case:
/sbin/lspci | grep -i vmware |wc -l
cat /etc/redhat-release
facter --version
export PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
facter virtual
export PATH=/usr/local/bin:/bin:/usr/bin
facter virtual
[root@sbox01 ~]# /sbin/lspci | grep -i vmware |wc -l #just to show it is indeed vmware
35
[root@sbox01 ~]# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 5.5 (Tikanga)
[root@sbox01 ~]# facter —version 1.5.8
[root@sbox01 ~]# export PATH=/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin
[root@sbox01 ~]# facter virtual
vmware
[root@sbox01 ~]# export PATH=/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin
[root@sbox01 ~]# facter virtual
physical
#2
Updated by James Turnbull over 2 years ago
- Category set to interface
- Status changed from Unreviewed to Needs Decision
- Assignee set to Paul Nasrat
#3
Updated by Ken Barber over 1 year ago
- Assignee deleted (
Paul Nasrat)
So the possible paths here are:
- We set the PATH ourselves to something sane, this if course is going to be problematic if someone has a binary in some unknown path
- We do something like opt 1, but provide a nob for changing this
- We do something like opt 2, but provide reasonable OS based lookups for setting the path to something meaningful
- We continue to trust the users path
- We statically provide a path to all our commands, but this will require case-based lookups for OS variations. As Adrien has mentioned we do this for facter/util/manufacturer
Some points:
I think continuing to trust the users PATH is a potential security flaw obviously, however – trusting the PATH however has led us to a reasonable amount of success no doubt, as it in effect provides the nob described in option 2. Albeit, a less trustworthy nob.
The truth though is that some facts use fully-qualified paths and some do not. In the case where a FQ path is not supplied, up until now the requirement of PATH has caught people by surprise but the workaround is easy enough. My greatest concern is that the ‘surprise’ is hard to debug since it fails silently.
The solution is for operating systems to put their binaries in 1 place, but alas thats not something Facter can solve.
In all honesty I don’t think any of these solutions is a silver bullet.
#4
Updated by Daniel Pittman over 1 year ago
- Status changed from Needs Decision to Accepted
Ken Barber wrote:
- We set the PATH ourselves to something sane, this if course is going to be problematic if someone has a binary in some unknown path
We should do this, or, rather, we should make sure that when a fact tries to run an unqualified command it will either fail hard, or only use a trusted path. Users who put commands in uncommon locations and don’t qualify them are probably hard on luck anyhow, given the environment that Puppet and Facter run in can be wildly unpredictable to start with.
#5
Updated by Daniel Pittman over 1 year ago
Daniel Pittman wrote:
Ken Barber wrote:
- We set the PATH ourselves to something sane, this if course is going to be problematic if someone has a binary in some unknown path
We should do this, or, rather, we should make sure that when a fact tries to run an unqualified command it will either fail hard, or only use a trusted path. Users who put commands in uncommon locations and don’t qualify them are probably hard on luck anyhow, given the environment that Puppet and Facter run in can be wildly unpredictable to start with.
…though, of course, don’t forget to account for the fact that Facter is a library that can be loaded into arbitrary software – so making global changes to the state of the system could break other consumers who quite reasonably don’t expect a library to go and fiddle with their PATH under them.