[chef] RE: Re: How to enhance an existing provider?

[Kevin Keane (subscriptions) < >]

Thank you so much! I'll check out the monkey patch; sounds just like what I 
need!

As for the assumption: I think there may be a better, and easier, way to go 
about that. SELinux already contains a database of all the contexts that 
files *should* have; you access it with the semanage fcontext command. The 
restorecon utility that I was planning to use simply looks in this database 
and applies whatever context RedHat/CentOS/... are supposed to have in the 
first place.

This is better because the assumption "use the containing directory's 
context" isn't always true. For instance, in the /usr/lib64/nagios/plugins 
directory, some plugins need to have unconfined context, while others will 
run fine confined.

By the way, an alternate approach would be to change how chef puts files in 
its destination. I think this would go too deep into Chef for me to do, 
though, but would be the best solution.

Currently, as far as I can tell, Chef creates a file in a temporary directory 
(which gives it the usr_tmp_t context) and then moves it into place (keeping 
the context). That's probably how the context gets clobbered in the first 
place. Instead, chef should first create the file in the temporary location, 
but instead of moving it, create a new one (which will have the correct 
SELinux context) and copy the content of the temporary file over.

In any case, thanks for your monkey patch! That's going to help me 
dramatically.

-----Original Message-----
From: Sean OMeara 
[mailto:
 
 
Sent: Tuesday, January 01, 2013 2:52 PM
To: 

 
Subject: [chef] Re: How to enhance an existing provider?

Look in libraries/monkey.rb

That particular code assumes that when you write a file, you want to give it 
the same selinux context as it's containing directory by default. Opinions on 
that?

It needs some heavy work and uses a raw string as the context representation 
instead of breaking it into its individual parts.

It's a start.

On Tue, Jan 1, 2013 at 5:46 PM, Sean OMeara 
<
 >
 wrote:
> Hi!
>
> Excellent question. The best way to do this is to use a cookbook to 
> monkey patch the Chef::Provider::File class, so you can experiment 
> with it without having to modify core Chef.
>
> As it turns out, I started making a pass at this very issue a few 
> years ago, but never got around to finishing it.
>
> Here's a good place to start!
>
> https://github.com/someara/cookbook-selinux/tree/monkeys
>
> Let me know if you have any questions or need any assistance.
>
> -s
>
> On Tue, Jan 1, 2013 at 5:26 PM,  
> <
 >
>  wrote:
>> I’m still on the up-slope of my Chef learning curve…
>>
>>
>>
>> What I’d like to do is enhance the Chef::Provider::File. It seems to 
>> me that the documentation section “Extending an existing provider” 
>> would apply here, but I don’t fully understand how it would work. I 
>> would create a mixin and put it into the library directory – and then 
>> what?  How would all my cookbooks – and the community ones I’m using - 
>> know to use this mixin?
>>
>>
>>
>>
>>
>> Specifically, what I’m trying to accomplish is fix one of the major 
>> annoyances in Chef; it not only doesn’t support SELinux, but actively 
>> clobbers the SELinux context for all he files, templates etc. that it 
>> creates. So my recipes are littered with execute resources for the 
>> “restorecon” utility to reset this everwhere I use a file-related 
>> resource (templates, remote_file, cookbook file etc.). It is becoming 
>> unmanageable, especially with community cookbooks that of course don’t 
>> have my hack added.
>>
>>
>>
>> Conceptually the fix is simple: in the file provider, in addition to 
>> setting the file permissions, I would also need to call restorecon.
>>
>>
>>
>> Rather than hacking the File resource itself, I would like to put 
>> this feature into my SELinux cookbook, and have that somehow add a 
>> Mixin to the File resource.
>>
>>
>>
>> I just can’t figure out how to do that.
>>
>>
>>
>> Thanks!
>>
>>