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!
To the extent that your services' behaviors depend on system resources
such as configuration files or certain directories, it is your
responsibility to describe those dependencies to Puppet (supposing you
managing them via Puppet). If you do, then Puppet will manage those
resources in the a sequence consistent with those dependencies.
The question, therefore, is not so much about how Puppet starts the
service, but rather about how to configure the service's SELinux context.
The thing is, because the service is started as unconfined_u, any
databases/tables that are created are going to inherit that, and
puppet
is going to be resetting them.
Puppet can be instructed to restart the service if resources on which
it depends are modified (by Puppet).
I don't want the service restarted, mysql doesn't care about the user
context itself, but puppet cares when it sees files being labelled as
unconfined_u instead of system_u (because matchpathcon tells it that
it's incorrect, rightly so)
For some more detail, I've written something which will set the
mysqld_db_t selinux file_context on my data directories which are in
/home, and I have a notify which will go and check and re-set the
selinux file_context if there are any changes in these directories.
They're set to recurse, so to stop Puppet changing things from
unconfined_u to system_u on a regular basis, and sending refresh
notices
to my Exec resources, I've set selinux_ignore_defaults to true in my
File resources.
This strikes me as a bit of a dirty way of doing things, and I was
wondering if anyone had any better ideas of how to manage this.
It strikes me as a backwards way of doing things. You are trying to
clean up the effects of a service misconfiguration instead of
configuring the service correctly in the first place.
Please find below a sample of the relevant code - because I'm sure my
verbose description is probably leaving some people scratching their
heads! :) I was going to make the file_context stuff much more
re-usable, but want to get my head around the best practices first
- as
I'm not that experiened with all of this stuff to be honest!
I'm afraid your code still leaves me scratching my head. I get the
feeling that you're doing a lot of work you don't need to be doing,
but I'm not conversant enough with MySQL SELinux configuration to know
what you should be doing instead.
It's a learning exercise :)
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/-/ojA1Ycp4YkkJ.
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-users?hl=en.
Thanks for getting back to me!
--
You received this message because you are subscribed to the Google Groups "Puppet
Users" 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-users?hl=en.
