Issue #17488 has been updated by Jeff McCune.
# Steps to reproduce
I've confirmed the issue, here's how I reproduced this issue on a CentOS 6
virtual machine.
Enabled SELinux:
<pre>
[jeff@pe-centos6 ~]$ cat /etc/selinux/config
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - No SELinux policy is loaded.
SELINUX=enforcing
# SELINUXTYPE= can take one of these two values:
# targeted - Targeted processes are protected,
# mls - Multi Level Security protection.
SELINUXTYPE=targeted
</pre>
Without the `libselinux-ruby` package installed, this is the expected behavior:
<pre>
[jeff@pe-centos6 ~]$ puppet apply --execute "file { '/root/chuj': ensure =>
absent; }"
warning: /Stage[main]//File[/root/chuj]: Could not stat; permission denied
notice: Finished catalog run in 0.03 seconds
[jeff@pe-centos6 ~]$ puppet apply --execute "file { '/root/chuj': ensure =>
absent; }" --noop
warning: /Stage[main]//File[/root/chuj]: Could not stat; permission denied
notice: Finished catalog run in 0.03 seconds
[jeff@pe-centos6 ~]$ puppet apply --noop --execute "file { '/root/chuj': ensure
=> absent; }"
warning: /Stage[main]//File[/root/chuj]: Could not stat; permission denied
notice: Finished catalog run in 0.03 seconds
</pre>
Once the `libselinux-ruby` package has been installed using `yum -y install
libselinux-ruby`, the issue becomes evident:
<pre>
[jeff@pe-centos6 ~]$ puppet apply --noop --execute "file { '/root/chuj': ensure
=> absent; }"
Permission denied - /root/chuj
</pre>
# Stack Traces
Here's the stack trace, which matches the debug file provided by Lubomir.
<pre>
[jeff@pe-centos6 ~]$ puppet apply --noop --trace --execute "file {
'/root/chuj': ensure => absent; }"
/workspace/puppet-3.x/src/puppet/lib/puppet/util/selinux.rb:45:in `lstat'
/workspace/puppet-3.x/src/puppet/lib/puppet/util/selinux.rb:45:in
`get_selinux_default_context'
/workspace/puppet-3.x/src/puppet/lib/puppet/type/file/selcontext.rb:39:in
`retrieve_default_context'
/workspace/puppet-3.x/src/puppet/lib/puppet/type/file/selcontext.rb:81:in
`default'
/workspace/puppet-3.x/src/puppet/lib/puppet/type.rb:547:in `set_default'
/workspace/puppet-3.x/src/puppet/lib/puppet/type.rb:1842:in `set_parameters'
/workspace/puppet-3.x/src/puppet/lib/puppet/type.rb:1841:in `each'
/workspace/puppet-3.x/src/puppet/lib/puppet/type.rb:1841:in `set_parameters'
/workspace/puppet-3.x/src/puppet/lib/puppet/type.rb:1805:in `initialize'
/workspace/puppet-3.x/src/puppet/lib/puppet/type/file.rb:434:in `initialize'
/workspace/puppet-3.x/src/puppet/lib/puppet/resource.rb:282:in `new'
/workspace/puppet-3.x/src/puppet/lib/puppet/resource.rb:282:in `to_ral'
/workspace/puppet-3.x/src/puppet/lib/puppet/resource/catalog.rb:618:in `send'
/workspace/puppet-3.x/src/puppet/lib/puppet/resource/catalog.rb:618:in
`to_catalog'
/workspace/puppet-3.x/src/puppet/lib/puppet/resource/catalog.rb:596:in `each'
/workspace/puppet-3.x/src/puppet/lib/puppet/resource/catalog.rb:596:in
`to_catalog'
/workspace/puppet-3.x/src/puppet/lib/puppet/resource/catalog.rb:521:in `to_ral'
/workspace/puppet-3.x/src/puppet/lib/puppet/application/apply.rb:221:in `main'
/workspace/puppet-3.x/src/puppet/lib/puppet/application/apply.rb:149:in
`run_command'
/workspace/puppet-3.x/src/puppet/lib/puppet/application.rb:309:in `run'
/workspace/puppet-3.x/src/puppet/lib/puppet/application.rb:416:in `hook'
/workspace/puppet-3.x/src/puppet/lib/puppet/application.rb:309:in `run'
/workspace/puppet-3.x/src/puppet/lib/puppet/application.rb:407:in `exit_on_fail'
/workspace/puppet-3.x/src/puppet/lib/puppet/application.rb:309:in `run'
/workspace/puppet-3.x/src/puppet/lib/puppet/util/command_line.rb:69:in `execute'
/workspace/puppet-3.x/src/puppet/bin/puppet:4
Permission denied - /root/chuj
</pre>
Next actions are to capture this exception in an example spec test. I'm
working on this action presently.
----------------------------------------
Bug #17488: Puppet needlessly crashes when run unptivileged even with --noop
https://projects.puppetlabs.com/issues/17488#change-76213
Author: Lubomir Rintel
Status: Tests Insufficient
Priority: Normal
Assignee: Jeff McCune
Category: user
Target version: 2.7.x
Affected Puppet version: 2.7.18
Keywords:
Branch: https://github.com/puppetlabs/puppet/pull/1269
I'm mostly opening this to satisfy comments in [pull request
1022](https://github.com/puppetlabs/puppet/pull/1022) even though I believe the
commit and pull comments were sufficiently descriptive.
Will open a new pull request, since the old one was closed due to my
unresponsiveness.
Repeating them here:
### Problem scope
I often run puppet --noop unprivileged to conduct a basic sanity check of the
recipes (such as checking for duplicate definitions or syntax errors).
These changesets fix unnecessary abort that cause puppet to stop way too early.
### First fix
Capture access violations for selinux context of file resources
and deal with them gracefully without aborting the run.
A simple reproducer of the problem (abort), to be run unprivileged:
<pre>
puppet apply --execute "file { '/root/chuj': ensure => absent; }"
</pre>
### Second fix
Don't abort while checking managedhome on nonexistent user provider.
The user resource itself should fail itself and this prevents falling back to
that.
Simple test case (unprivileged):
<pre>
before$ puppet apply --execute 'user { "kokot": managehome => true }'
Parameter managehome failed: Validate method failed for class managehome:
undefined method `manages_homedir?' for NilClass:Class
</pre>
<pre>
after$ puppet apply --execute 'user { "kokot": managehome => true }'
err: Could not find a suitable provider for user
notice: Finished catalog run in 0.10 seconds
</pre>
### Test suite
Unfortunately I can not write tests for this; since I could not get Puppet test
suite pass sufficiently well on my laptop and I have no idea how is it supposed
to work, let alone testing for fixes for issues that exhibit different
behaviour when run privileged. I would be very thankful if anyone could assist.
--
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.
