[colug-432] Puppet + Subversion + SELinux

[R P Herrold]

On Thu, 24 Feb 2011, Scott Merrill wrote:

>>> type=AVC msg=audit(1298560237.269:186279): avc:  denied  { getattr }
>>> for  pid=3254 comm="puppetmasterd"
>>> path="/usr/local/puppet/manifests/site.pp" dev=dm-0 ino=5224
>>> scontext=unconfined_u:system_r:puppetmaster_t:s0
>>> tcontext=unconfined_u:object_r:httpd_sys_content_t:s0 tclass=file
>>
>> again, the .pp script is read-blocked, and so will fail is a
>> manner which might be predicted by examining the caller and
>> the code not able to be read
>
> So here's where things get interesting to me.
>
> Out of the box, I would expect the puppetmasterd daemon to have the
> necessary (SELinux) permissions to read /etc/puppet, since that's
> where the files live, by default.
>
> The actual denial is { getattr }. Does that prevent the reading of the
> file altogether? That's not entirely clear to me.

When the puppetmasterd process 'stat's the file, this is 
blocked, and any later read will fail, as the puppetmasterd 
(probably) concludes from the failed stat that there no file 
there, that there is a permissions problem, or such.  We would 
have to strace the code to see just where the read is being 
attempted, but the bottom line is that the 'denied' needs to 
be resolved [see the scripts annexed to my prior reference to 
the blog posts]
 	/usr/local/puppet/manifests/site.pp
that is being blocked.  This is not down the tree:
 	/etc/puppet

... later

>> [Subversion is NOT where the 'cool kids' play these days --
>> they have all moved to the 'git' dvcs, and github and
>> work-alikes, it seems  ;) ]
>
> Subversion works. It does exactly what we need. I don't need
> distributed revision control for this application, and I've yet to
> have anyone articulate any situations in which I really do need a
> DVCS. If anyone has any such explications, please consider presenting
> your arguments in the form of a COLUG presentation!

No criticism, and I note Jim weighed in as well.  Luddite that 
I am, I actually still use (as in earlier today did a ci and 
co) RCS  :)

But in a commercial project I've also been using 'git', and it 
seems robust and secure

-- Russ herrold