Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I am running into an issue every time I attempt to start the puppetmasterd service, for which I receive the following error message:

root@service1 ~ # -> /etc/init.d/puppetmaster start
Starting puppetmaster: Could not prepare for execution: Got 1 failure(s) while initializing: change from absent to directory failed: Could not set 'directory on ensure: Permission denied - /etc/puppet/ssl
                                                       [FAILED]

Apparently there was a known issue with this scenario as outlined in this bug report, however in the bug report it states the issue has been resolved in selinux-policy-3.9.16-29.fc15, but the latest CentOS default upstream version is 3.7.19-155.el6_3.4. So I am trying to figure out the best solution.

I can either create a local security policy to allow puppetmasterd the access it needs, or keep researching and install a newer version of selinux-policy outside of the default upstream channel. Anyone have any recommendations? Please don't recommend disabling SELinux...

----- Update -----

Here is the puppet.conf:

[main]
    # The Puppet log directory.
    # The default value is '$vardir/log'.
    logdir = /var/log/puppet

    # Where Puppet PID files are kept.
    # The default value is '$vardir/run'.
    rundir = /var/run/puppet

    # Where SSL certificates are kept.
    # The default value is '$confdir/ssl'.
    ssldir = $vardir/ssl

[master]
    certname=puppetmaster.ownij.lan
    dns_alt_names=puppetmaster.ownij.lan

[agent]
    # The file in which puppetd stores a list of the classes
    # associated with the retrieved configuratiion.  Can be loaded in
    # the separate ``puppet`` executable using the ``--loadclasses``
    # option.
    # The default value is '$confdir/classes.txt'.
    classfile = $vardir/classes.txt

    # Where puppetd caches the local configuration.  An
    # extension indicating the cache format is added automatically.
    # The default value is '$confdir/localconfig'.
    localconfig = $vardir/localconfig

    server=puppetmaster.ownij.lan

And here are the denials per the audit log:

type=AVC msg=audit(1349751364.985:666): avc:  denied  { search } for  pid=15093 comm="puppetmasterd" name="/" dev=dm-2 ino=2 scontext=unconfined_u:system_r:puppetmaster_t:s0 tcontext=system_u:object_r:home_root_t:s0 tclass=dir
type=SYSCALL msg=audit(1349751364.985:666): arch=c000003e syscall=4 success=no exit=-13 a0=1391420 a1=7fffef09ed10 a2=7fffef09ed10 a3=120c500 items=0 ppid=15092 pid=15093 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=13 comm="puppetmasterd" exe="/usr/bin/ruby" subj=unconfined_u:system_r:puppetmaster_t:s0 key=(null)
type=AVC msg=audit(1349751365.302:667): avc:  denied  { search } for  pid=15093 comm="puppetmasterd" name="/" dev=dm-2 ino=2 scontext=unconfined_u:system_r:puppetmaster_t:s0 tcontext=system_u:object_r:home_root_t:s0 tclass=dir
type=SYSCALL msg=audit(1349751365.302:667): arch=c000003e syscall=4 success=no exit=-13 a0=1d18530 a1=7fffef0d04d0 a2=7fffef0d04d0 a3=8 items=0 ppid=15092 pid=15093 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=13 comm="puppetmasterd" exe="/usr/bin/ruby" subj=unconfined_u:system_r:puppetmaster_t:s0 key=(null)
type=AVC msg=audit(1349751365.465:668): avc:  denied  { search } for  pid=15093 comm="puppetmasterd" name="/" dev=dm-2 ino=2 scontext=unconfined_u:system_r:puppetmaster_t:s0 tcontext=system_u:object_r:home_root_t:s0 tclass=dir
type=SYSCALL msg=audit(1349751365.465:668): arch=c000003e syscall=4 success=no exit=-13 a0=1af3930 a1=7fffef0c5c70 a2=7fffef0c5c70 a3=8 items=0 ppid=15092 pid=15093 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=13 comm="puppetmasterd" exe="/usr/bin/ruby" subj=unconfined_u:system_r:puppetmaster_t:s0 key=(null)
type=AVC msg=audit(1349751365.467:669): avc:  denied  { search } for  pid=15093 comm="puppetmasterd" name="/" dev=dm-2 ino=2 scontext=unconfined_u:system_r:puppetmaster_t:s0 tcontext=system_u:object_r:home_root_t:s0 tclass=dir
type=SYSCALL msg=audit(1349751365.467:669): arch=c000003e syscall=4 success=no exit=-13 a0=1b17aa0 a1=7fffef0c5c70 a2=7fffef0c5c70 a3=8 items=0 ppid=15092 pid=15093 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=13 comm="puppetmasterd" exe="/usr/bin/ruby" subj=unconfined_u:system_r:puppetmaster_t:s0 key=(null)
type=AVC msg=audit(1349751366.401:670): avc:  denied  { write } for  pid=15093 comm="puppetmasterd" name="puppet" dev=dm-0 ino=132035 scontext=unconfined_u:system_r:puppetmaster_t:s0 tcontext=system_u:object_r:puppet_etc_t:s0 tclass=dir
type=SYSCALL msg=audit(1349751366.401:670): arch=c000003e syscall=83 success=no exit=-13 a0=2d7a400 a1=1f9 a2=2d7a40f a3=7fffef0a6df0 items=0 ppid=15092 pid=15093 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=13 comm="puppetmasterd" exe="/usr/bin/ruby" subj=unconfined_u:system_r:puppetmaster_t:s0 key=(null)

And the audit log if I pass through audit2allow:

root@service1 ~ # -> fgrep puppetmasterd /var/log/audit/audit.log | audit2allow -m puppetmasterd

module puppetmasterd 1.0;

require {
    type home_root_t;
    type puppetmaster_t;
    type puppet_etc_t;
    type puppet_var_run_t;
    type httpd_sys_content_t;
    class lnk_file { relabelfrom relabelto };
    class file { relabelfrom read getattr open };
    class dir { write read search getattr setattr };
}

#============= puppetmaster_t ==============
allow puppetmaster_t home_root_t:dir { search getattr };
allow puppetmaster_t httpd_sys_content_t:dir read;
allow puppetmaster_t httpd_sys_content_t:file { read getattr open };
#!!!! The source type 'puppetmaster_t' can write to a 'dir' of the following types:
# puppet_log_t, puppet_var_lib_t, puppet_var_run_t, puppetmaster_tmp_t

allow puppetmaster_t puppet_etc_t:dir { write setattr };
allow puppetmaster_t puppet_etc_t:lnk_file { relabelfrom relabelto };
allow puppetmaster_t puppet_var_run_t:file relabelfrom;
share|improve this question
    
I do not have the time to write this up as a correct answer, but see my policy at sandcat.nl/~stijn/2012/01/20/selinux-passenger-and-puppet-oh-my –  Stijn Hoop Oct 10 '12 at 11:48

1 Answer 1

up vote 0 down vote accepted

You're using the default location for $ssldir - what's your puppet.conf look like?

The default deployment of Puppet on RHEL derivatives has a puppet.conf with something like the following:

[main]
    ssldir = /var/lib/puppet/ssl

If you put this back in place, the SELinux policy shouldn't have a problem with the location of your SSL directory.

share|improve this answer
    
Yes, I believe it is in the default location as I didn't overwrite that setting in the puppet.conf. –  Mike Purcell Oct 9 '12 at 3:10
    
@MikePurcell Right - I'm saying that puppet.conf's default location of $confdir/ssl (which is what your config is using) is not the standard RHEL/CentOS location of /var/lib/puppet/ssl (or $vardir/ssl). Try using the normal CentOS location and I bet your issue will be resolved. By the way, what method did you use to install Puppet? –  Shane Madden Oct 9 '12 at 3:13
    
Used yum install puppet\* --enablerepo=epel –  Mike Purcell Oct 9 '12 at 4:10
    
What is the "normal centos location"? –  Mike Purcell Oct 9 '12 at 4:18
    
"the standard RHEL/CentOS location of /var/lib/puppet/ssl (or $vardir/ssl)" –  m0dlx Oct 9 '12 at 5:49

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.