Bug #12336
executing system commands may fail if user's PATH contains a tilde
| Status: | Merged - Pending Release | Start date: | 01/31/2012 | |
|---|---|---|---|---|
| Priority: | Low | Due date: | ||
| Assignee: |  Chris Price |
% Done: | 0% |
|
| Category: | exec | |||
| Target version: | 3.0.0 | |||
| Affected Puppet version: | Branch: | https://github.com/puppetlabs/puppet/pull/473 | ||
| Keywords: | ||||
| Votes: | 0 |
Description
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.
Related issues
History
Updated by Patrick Carlisle 4 months ago
- Status changed from Unreviewed to Accepted
Updated by Chris Price 3 months 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.
Updated by Chris Price 3 months 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.
Updated by Daniel Pittman 3 months ago
- Category set to exec
- Status changed from In Topic Branch Pending Review to Merged - Pending Release
- Target version set to 3.X
Updated by Daniel Pittman 7 days ago
- Target version changed from 3.X to 3.0.0