Issue #5013 has been updated by Ken Barber. Assignee deleted (Paul Nasrat)
So the possible paths here are: 1. 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 2. We do something like opt 1, but provide a nob for changing this 3. We do something like opt 2, but provide reasonable OS based lookups for setting the path to something meaningful 4. We continue to trust the users path 5. 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. ---------------------------------------- Bug #5013: Facter assumes path that isn't there always https://projects.puppetlabs.com/issues/5013#change-55048 Author: Michael Stahnke Status: Needs Decision Priority: Normal Assignee: Category: interface Target version: Keywords: Branch: Affected Facter version: 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. <pre> /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 </pre> Output from this test case: <pre> [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** </pre> 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. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
