On Wednesday, October 10, 2012 3:19:17 PM UTC-5, Tom B. wrote: > > On 10/10/12 16:09, jcbollinger wrote: > > > > On Tuesday, October 9, 2012 10:02:26 AM UTC-5, Tom B. wrote: >> >> Hi list, >> >> I've got an issue at the moment, which isn't really a big problem, but >> an untidy annoyance really, and I'd just like to understand what the >> best practice might be when dealing with the issue. >> >> As a really quick summary, the issue is that Puppet is starting up the >> mysqld service for the first time as unconfined_u, and then when MySQL >> goes and creates a load of its initial files also as unconfined_u, >> Puppet goes and resets them all to system_u which is what they should be >> when checking matchpathcon: >> >> > Unless you configure it differently, Puppet uses the system's normal > service management commands to control services. It is the responsibility > of that tool (e.g. /sbin/service) to start the service in the correct way, > including SELinux context, based on whatever criteria it uses to choose > such things. Among other things, this means that you will get the same > result if Puppet starts the service as you would if the system > initialization program starts it at boot. > > by using runcon or run_init you are starting the service in the same > context that it will be started with at system boot by init. /sbin/service > is not the correct way to start an selinux confined service technically, > although practically it makes little difference because user contexts are > not heavily used in the targeted selinux policy, unless users themselves > are confined, which they usually aren't. Perhaps there should be an > selinux aware provider for services >
Certainly Puppet's Linux-relevant providers should be SELinux-friendly, or else it should have a separate set of providers, and choose those automatically when it finds SELinux enabled. My limited research suggests that at least on RedHat-family systems, /sbin/service is supposed to be the correct command to use to manage services even under SELinux; it is expected (at least by some) to start the target service in the right context. Upon looking at the code (CentOS 5 and CentOS 6), however, it does not appear to do anything special to take the SELinux context into account. In effect, that delegates responsibility to the service control script. That's not unreasonable, really; I would account it part of the control script's job to run the service in the correct context. Now, RedHat-family Linuxes do have run_init, which leaves me a bit perplexed. Moreover, its docs seem to indicate that it reads the context to use from /etc/selinux/<POLICYTYPE>/contexts/initrc_context, and for my version of the targeted policy that file contains "user_u:system_r:initrc_t:s0". I don't think that would get you system_u, either. In the end, therefore, I think on these systems it does still come down to the initscript's and / or the daemon's own job to run the daemon in the appropriate context. If you are on a different Linux family, however, then you may have a more viable issue against Puppet. On a lot of systems, including Debian and Gentoo, Puppet manages services by directly invoking the initscripts. If there is a different command that Puppet should be using instead then I'm sure PuppetLabs would appreciate you filing a ticket to tell them about it. In any event, I maintain that it would be inappropriate for Puppet to provide for explicitly setting the SELinux context to use for starting services. The system initialization program -- whether init, upstart, or something else -- either knows somehow which context to use for each service, or else delegates to individual services' configurations to choose this. Puppet should be able to do the same. Moreover, I reiterate that the best solution would be to configure the service correctly in the first place. If that's not viable (e.g. if it would require modifying the initscript and you are unwilling to do that) then you have the alternative of writing a custom provider for the Service type, and explicitly directing that provider to be used where needed in your Service declarations. There are good base classes and a lot of examples of Service providers in the Puppet distribution, so I don't think that would be so hard. You definitely should not need to come back and correct files' SELinux contexts after the fact. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/A0_F_SrsfUQJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
