The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com
https://tickets.puppetlabs.com. See the following page for information on filing tickets with JIRA:
executing system commands may fail if user's PATH contains a tilde
|Assignee:||Chris Price||% Done:|
|Affected Puppet version:||Branch:||https://github.com/puppetlabs/puppet/pull/473|
Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com
As a result of the changes from #5224, we are now unsetting the HOME environment variable when we execute system commands from within puppet. (This applies mostly to the Exec provider, but may also affect other providers that issue system commands.)
An exception will be thrown if the following conditions are met:
- User’s PATH contains a literal ‘~’ character
- The command to be executed is not specified via an absolute path
Should be reproducible by adding, e.g., “~/bin” to PATH and then running the spec/unit/util_spec.rb tests.
#2 Updated by Chris Price almost 4 years ago
I can see a few different ways to handle this:
- If we find a “~” in the user’s PATH, ignore that element from the path and print a warning.
- Attempt to capture the user’s HOME environment variable when puppet starts up, and cache it somewhere. Refer back to that when we are attempting to expand the “~” PATH element.
The first solution would be cleaner, but would be unable to execute binaries that were installed in a user’s home directory unless they change their PATH to be absolute (rather than using the “~”). The second solution would be more bullet-proof but might require the introduction of some kind of semi-global variable to cache the value in—which would not be the end of the world, but is a little messier than the first solution.
#3 Updated by Chris Price almost 4 years ago
- Status changed from Accepted to In Topic Branch Pending Review
- Branch set to https://github.com/puppetlabs/puppet/pull/473
Added a pull request for this.
Note that the test in question was one of the “which” tests in util_spec.rb. The reporter who initially found this reported that he DID have his “HOME” environment variable set, which theoretically means that this test shouldn’t have failed for him.
I suspect that the failure was being seen due to a combination between this bug and bug #12490, which was causing HOME to be unset as a side effect of a bad spec test.
I did add a test that reproduces this w/o depending on that side effect, and I think that this fix is still worthwhile. It basically amounts to slightly better error handling, which is never a bad thing.