http://projects.puppetlabs.com/2010-11-30T06:21:46ZPuppet LabsPuppet - Bug #5224: puppetd does not set environment correctly from Exechttp://projects.puppetlabs.com/issues/5224?journal_id=220502010-11-30T06:21:46ZNigel Kerstennigel@puppetlabs.com
<ul><li><strong>Status</strong> changed from <i>Unreviewed</i> to <i>Accepted</i></li></ul> Puppet - Bug #5224: puppetd does not set environment correctly from Exechttp://projects.puppetlabs.com/issues/5224?journal_id=297622011-04-30T09:43:21ZJames Turnbulljames@lovedthanlost.net
<ul><li><strong>Status</strong> changed from <i>Accepted</i> to <i>Needs Decision</i></li><li><strong>Assignee</strong> set to <i>Nigel Kersten</i></li></ul><p>See support URL update.</p>
Puppet - Bug #5224: puppetd does not set environment correctly from Exechttp://projects.puppetlabs.com/issues/5224?journal_id=299382011-05-04T00:13:58ZNigel Kerstennigel@puppetlabs.com
<ul><li><strong>Status</strong> changed from <i>Needs Decision</i> to <i>Rejected</i></li></ul><blockquote>
it also seems sensible to document the behaviour and make it consistent irrespective of how puppetd is started. cron' default behaviour seems like a reasonable starting point.
</blockquote>
<p>On the other hand, we have users who expect the environment for an Exec to be consistent with the environment that puppetd was launched in, and we can&rsquo;t satisfy both sets.</p>
<p>It&rsquo;s quite reasonable for us to use the environment puppet was invoked in, which will vary depending on how you do it (and across platforms, and versions of platforms, and across different tools for invoking services)</p>
<p>There is a simple method if you want to enforce a given environment for all your Exec resources.</p>
<p>Set a resource default for Exec that defines the desired environment at your top level scope, and it will be applied to all Exec resources.</p>
Puppet - Bug #5224: puppetd does not set environment correctly from Exechttp://projects.puppetlabs.com/issues/5224?journal_id=480222011-12-13T21:00:26ZAnonymous
<ul><li><strong>Status</strong> changed from <i>Rejected</i> to <i>Re-opened</i></li></ul><p>An update on this&hellip;</p>
<p>While I agree that users expect the regular Puppet context to be in place, Bad Things happen when $USER and $HOME are explicitly set by Puppet.</p>
<p>After a conversation with Daniel Pittman, we thought that perhaps deleting both values, rather than explicitly setting them, might be a sane alternative.</p>
<p>Is that a possibility, or do we really want to leave this as it stands?</p>
<p>-Eric</p>
Puppet - Bug #5224: puppetd does not set environment correctly from Exechttp://projects.puppetlabs.com/issues/5224?journal_id=480232011-12-13T21:05:28ZAnonymous
<ul><li><strong>Status</strong> changed from <i>Re-opened</i> to <i>Needs Decision</i></li></ul><p>Eric Shamow wrote:</p>
<blockquote><p>While I agree that users expect the regular Puppet context to be in place, Bad Things happen when $USER and $HOME are explicitly set by Puppet.</p></blockquote>
<p>Specifically, plenty of Unix software makes the assumption that you can do the equivalent of this:</p>
<pre>
user = ENV["USER"] || ENV["LOGNAME"] || getpwuid($CURRENT_UID)
home = ENV["HOME"] || getpwthing["home"]
</pre>
<blockquote><p>After a conversation with Daniel Pittman, we thought that perhaps deleting both values, rather than explicitly setting them, might be a sane alternative.</p></blockquote>
<p>Specifically, if we are changing user in Puppet from root to another uid for the exec, we might want to have either a whitelist of preserved environment values, or a blacklist of deleted environment values.</p>
<p>I would strongly favour encouraging people to, eg, use the <code>environment</code> property in Puppet to preserve state explicitly through, but if we absolutely prefer this risky preserve-by-default behaviour, having a blacklist of things to remove because they are now totally wrong seems like a trade-off.</p>
<p>A sudo-like &ldquo;preserve these variables&rdquo; option would be another path: for most people, preserve a short whitelist of safe things on exec, and allow people to expand that themselves when they want to.</p>
<p>Ultimately, lots of Unix software assumes that $USER, $LOGNAME, and $HOME are accurate <em>if</em> they are present, and prefers them to any other source of information.</p>
Puppet - Bug #5224: puppetd does not set environment correctly from Exechttp://projects.puppetlabs.com/issues/5224?journal_id=483012011-12-14T19:59:13ZNigel Kerstennigel@puppetlabs.com
<ul><li><strong>Assignee</strong> changed from <i>Nigel Kersten</i> to <i>Anonymous</i></li></ul><p>I&rsquo;m not in favor of us adding more configuration options for this behavior, but I&rsquo;m ok with &ldquo;having a blacklist of things to remove because they are now totally wrong&rdquo;.</p>
Puppet - Bug #5224: puppetd does not set environment correctly from Exechttp://projects.puppetlabs.com/issues/5224?journal_id=499412012-01-04T00:19:35ZAnonymous
<ul><li><strong>Status</strong> changed from <i>Needs Decision</i> to <i>Accepted</i></li><li><strong>Priority</strong> changed from <i>Normal</i> to <i>High</i></li></ul> Puppet - Bug #5224: puppetd does not set environment correctly from Exechttp://projects.puppetlabs.com/issues/5224?journal_id=511512012-01-18T21:19:02ZChris Price
<ul><li><strong>Assignee</strong> changed from <i>Anonymous</i> to <i>Chris Price</i></li></ul> Puppet - Bug #5224: puppetd does not set environment correctly from Exechttp://projects.puppetlabs.com/issues/5224?journal_id=528492012-01-26T20:35:58ZChris Price
<ul></ul><p>So what is the final verdict here? Simply remove HOME, USER, LOGNAME for the duration of an &ldquo;exec&rdquo;?</p>
Puppet - Bug #5224: puppetd does not set environment correctly from Exechttp://projects.puppetlabs.com/issues/5224?journal_id=528572012-01-26T21:08:29ZAnonymous
<ul></ul><p>Chris Price wrote:</p>
<blockquote><p>So what is the final verdict here? Simply remove HOME, USER, LOGNAME for the duration of an &ldquo;exec&rdquo;?</p></blockquote>
<p>That seems like a solid starting point.</p>
Puppet - Bug #5224: puppetd does not set environment correctly from Exechttp://projects.puppetlabs.com/issues/5224?journal_id=531292012-01-27T22:49:53ZChris Price
<ul></ul><p>Notes on solution (pending github pull request and code review):</p>
<ul>
<li>we are now unsetting &ldquo;HOME&rdquo;, &ldquo;USER&rdquo;, and &ldquo;LOGNAME&rdquo; for the duration of any process that is launched by puppet.</li>
<li>had some concerns about the best way to ensure that we still respected the custom &ldquo;environment&rdquo; property defined in an Exec resource; we were formally handling the temporary environment var manipulation directly in the exec provider, but this would have made it tricky to know which user-related environment vars to unset further down in the code (in Util.execute<em>*). Instead, we now handle the temporary/custom environment variable manipulation (e.g., from Exec resource &ldquo;environment&rdquo; property) all the way down inside of the Util.execute</em>* methods. This way there is no chance that Exec resource&rsquo;s &ldquo;environment&rdquo; vars are stomped on in between the provider code and the final execution code.</li>
<li>This also allows the possibility for exec commands to be called with custom environment variable settings from other spots in our code, which seems generally useful.</li>
<li>a different idea that was discussed was the possibility of simply unsetting HOME/USER/LOGNAME globally at puppet startup; I decided against this for a few different reasons. First, globally modifying environment variables seems a bit frightening. Second, concern about unintended side effects; we just dealt with a similar set of problems due to the fact that Facter was globally setting ENV[&lsquo;LANG&rsquo;] to &lsquo;C&rsquo; and causing unintended side effects. Third, keeping the scope of these overrides as narrow as possible limits the possibility that other Ruby code (e.g., user&rsquo;s custom module code) does something unexpected to them in between puppet startup and the point in time when we launch processes.</li>
</ul>
Puppet - Bug #5224: puppetd does not set environment correctly from Exechttp://projects.puppetlabs.com/issues/5224?journal_id=531302012-01-27T22:50:42ZChris Price
<ul><li><strong>Status</strong> changed from <i>Accepted</i> to <i>In Topic Branch Pending Review</i></li><li><strong>Branch</strong> set to <i>https://github.com/puppetlabs/puppet/pull/418</i></li></ul> Puppet - Bug #5224: puppetd does not set environment correctly from Exechttp://projects.puppetlabs.com/issues/5224?journal_id=532662012-01-30T22:15:29ZAnonymous
<ul><li><strong>Status</strong> changed from <i>In Topic Branch Pending Review</i> to <i>Merged - Pending Release</i></li><li><strong>Target version</strong> set to <i>3.x</i></li></ul> Puppet - Bug #5224: puppetd does not set environment correctly from Exechttp://projects.puppetlabs.com/issues/5224?journal_id=533432012-01-31T08:32:51ZJeff Weissjeff.weiss@puppetlabs.com
<ul></ul><p>After the merge of this pull request, I get failing tests in <code>spec/unit/util_spec.rb</code> on OS X 10.7.</p>
<p>Specifically,</p>
<pre>
1) Puppet::Util#which should return nil if no executable found
Failure/Error: Puppet::Util.which('doesnotexist').should be_nil
ArgumentError:
couldn't find HOME environment -- expanding `~/bin/doesnotexist'
# ./lib/puppet/util.rb:180:in `expand_path'
# ./lib/puppet/util.rb:180:in `which'
# ./lib/puppet/util.rb:179:in `each'
# ./lib/puppet/util.rb:179:in `which'
# ./spec/unit/util_spec.rb:613
</pre>
<p>I confirmed it was this merge by double-checking previous commit commit:7f09df4c320c1a2a959ae73e4a74648942f0fc52.</p>
<p>Other maybe useful stuff:</p>
<pre>
MacBook-Pro:puppet jeff$ uname -a
Darwin MacBook-Pro.local 11.2.0 Darwin Kernel Version 11.2.0: Tue Aug 9 20:54:00 PDT 2011; root:xnu-1699.24.8~1/RELEASE_X86_64 x86_64
MacBook-Pro:puppet jeff$ ruby -v
ruby 1.8.7 (2011-06-30 patchlevel 352) [i686-darwin11.1.0]
MacBook-Pro:puppet jeff$ set | grep "^HOME"
HOME=/Users/jeff
</pre>
Puppet - Bug #5224: puppetd does not set environment correctly from Exechttp://projects.puppetlabs.com/issues/5224?journal_id=533642012-01-31T17:20:14ZChris Price
<ul></ul><p>Hi Jeff,</p>
<p>Are you running the specs as your normal user account? Or as root? With sudo perhaps? I&rsquo;m not able to repro this so far. I&rsquo;m using exactly the same kernel as you, but ruby 1.8.7-357. However, the error message looks like an OS-level message to me, as opposed to a ruby message.</p>
Puppet - Bug #5224: puppetd does not set environment correctly from Exechttp://projects.puppetlabs.com/issues/5224?journal_id=533702012-01-31T17:53:34ZJeff Weissjeff.weiss@puppetlabs.com
<ul></ul><p>Running as normal user. Upgraded to 1.8.7-p357. Still happens.</p>
<pre>
Failures:
1) Puppet::Util#which should return nil if no executable found
Failure/Error: Puppet::Util.which('doesnotexist').should be_nil
ArgumentError:
couldn't find HOME environment -- expanding `~/bin/doesnotexist'
# ./lib/puppet/util.rb:180:in `expand_path'
# ./lib/puppet/util.rb:180:in `which'
# ./lib/puppet/util.rb:179:in `each'
# ./lib/puppet/util.rb:179:in `which'
# ./spec/unit/util_spec.rb:613
Finished in 176.83 seconds
14485 examples, 1 failure, 88 pending
Failed examples:
rspec ./spec/unit/util_spec.rb:612 # Puppet::Util#which should return nil if no executable found
MacBook-Pro:puppet jeff$ history | tail
593 gem install facter
594 gem list
595 gem install racc
596 gem install rack
597 gem install mocha
598 gem install ruby-debug
599 gem list
600 gem list | less
601 rspec spec/
602 history | tail
MacBook-Pro:puppet jeff$ ruby -v
ruby 1.8.7 (2011-12-28 patchlevel 357) [i686-darwin11.2.0]
MacBook-Pro:puppet jeff$ uname -a
Darwin MacBook-Pro.local 11.2.0 Darwin Kernel Version 11.2.0: Tue Aug 9 20:54:00 PDT 2011; root:xnu-1699.24.8~1/RELEASE_X86_64 x86_64M
MacBook-Pro:puppet jeff$ gem list
*** LOCAL GEMS ***
columnize (0.3.6)
diff-lcs (1.1.3)
facter (1.6.5)
linecache (0.46)
metaclass (0.0.1)
mocha (0.10.3)
racc (1.4.7)
rack (1.4.1)
rake (0.8.7)
rbx-require-relative (0.0.5)
rspec (2.6.0)
rspec-core (2.6.4)
rspec-expectations (2.6.0)
rspec-mocks (2.6.0)
ruby-debug (0.10.4)
ruby-debug-base (0.10.4)
</pre>
Puppet - Bug #5224: puppetd does not set environment correctly from Exechttp://projects.puppetlabs.com/issues/5224?journal_id=533752012-01-31T18:11:10ZChris Price
<ul></ul><p>Would you mind trying the following?</p>
<pre><code>which doesnotexist
printenv HOME
unset HOME
which doesnotexist
</code></pre>
Puppet - Bug #5224: puppetd does not set environment correctly from Exechttp://projects.puppetlabs.com/issues/5224?journal_id=533772012-01-31T18:18:12ZJeff Weissjeff.weiss@puppetlabs.com
<ul></ul><pre>
MacBook-Pro:puppet jeff$ which doesnotexist
MacBook-Pro:puppet jeff$ printenv HOME
/Users/jeff
MacBook-Pro:puppet jeff$ unset HOME
MacBook-Pro:puppet jeff$ which doesnotexist
MacBook-Pro:puppet jeff$
</pre>
Puppet - Bug #5224: puppetd does not set environment correctly from Exechttp://projects.puppetlabs.com/issues/5224?journal_id=533802012-01-31T18:23:20ZChris Price
<ul></ul><p>Ah, I think I see it.</p>
<p>Can you do this:</p>
<pre><code> printenv PATH
</code></pre>
<p>I am guessing that you have ~/bin in your path (literally, with the ~). If that&rsquo;s the case we can explore options from there.</p>
Puppet - Bug #5224: puppetd does not set environment correctly from Exechttp://projects.puppetlabs.com/issues/5224?journal_id=533812012-01-31T18:27:24ZJeff Weissjeff.weiss@puppetlabs.com
<ul></ul><p>Yep.</p>
<pre>
MacBook-Pro:puppet jeff$ printenv PATH
/Users/jeff/.rvm/gems/ruby-1.8.7-p357@puppet/bin:/Users/jeff/.rvm/gems/ruby-1.8.7-p357@global/bin:/Users/jeff/.rvm/rubies/ruby-1.8.7-p357/bin:/Users/jeff/.rvm/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:~/bin
</pre>
Puppet - Bug #5224: puppetd does not set environment correctly from Exechttp://projects.puppetlabs.com/issues/5224?journal_id=533942012-01-31T19:01:46ZChris Price
<ul></ul><p>Created ticket <a href="http://projects.puppetlabs.com/issues/12336" class="issue status-5 priority-3 priority-lowest closed" title="executing system commands may fail if user&#x27;s PATH contains a tilde (Closed)">#12336</a>. This seems likely to be a fairly uncommon scenario, and can be worked around via specifying an absolute path for a command (or removing the ~ element from the PATH environment variable), so I&rsquo;ve set the priority to Low for the moment; will solicit input on that via puppet-dev email list. Thanks for helping to uncover this!</p>
Puppet - Bug #5224: puppetd does not set environment correctly from Exechttp://projects.puppetlabs.com/issues/5224?journal_id=623012012-05-09T19:03:41ZAnonymous
<ul><li><strong>Target version</strong> changed from <i>3.x</i> to <i>3.0.0</i></li></ul> Puppet - Bug #5224: puppetd does not set environment correctly from Exechttp://projects.puppetlabs.com/issues/5224?journal_id=719232012-09-27T00:33:28ZMatthaus Owens
<ul><li><strong>Status</strong> changed from <i>Merged - Pending Release</i> to <i>Closed</i></li></ul><p>Merged at <a href="https://github.com/puppetlabs/puppet/commit/14670c5850462472f5efcfc6ea11d2b4cab708a7">https://github.com/puppetlabs/puppet/commit/14670c5850462472f5efcfc6ea11d2b4cab708a7</a></p>
<p>Released in Puppet 3.0.0rc1</p>
Puppet - Bug #5224: puppetd does not set environment correctly from Exechttp://projects.puppetlabs.com/issues/5224?journal_id=887472013-04-06T02:14:06ZCharlie Sharpsteen
<ul><li><strong>Keywords</strong> changed from <i>exec,crontab,service,environment,HOME</i> to <i>exec,crontab,service,environment,HOME customer</i></li></ul>