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:
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.
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.
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!
Many thanks. Tom.
# List of directories we''re going to use with MySQL
$mysqldirs = [ "/home/data", "/home/logs",
"/home/mysqltmp", ]
# Set SELinux contexts
define add_selinux_context ($context = "mysqld_db_t") {
file { $name:
ensure => "directory",
owner => "mysql",
group => "mysql",
seltype => "mysqld_db_t",
selinux_ignore_defaults => "true",
recurse => "true",
require => Package["mysql-server"],
notify => [ Exec["add_file_context_${context}_${name}"],
Exec["set_file_context_${context}_${name}"], ],
}
# Set the default file_context regex for the path
exec { "add_file_context_${context}_${name}":
command => "semanage fcontext -a -t ${context}
\"${name}(/.*)?\"",
unless => "semanage fcontext -l | grep
''^${name}(/.*)?:${context}:''",
require => [ Package["policycoreutils-python"], File[$name],
],
refreshonly => "true",
}
# Reset the file_context using restorecon
exec { "set_file_context_${context}_${name}":
command => "restorecon -R ${name}",
unless => "ls -d --scontext ${name} | awk -F: ''{print
\$3}'' |
grep \"${context}\"",
require => File["$name"],
refreshonly => "true",
}
}
add_selinux_context { $mysqldirs:
context => "mysqld_db_t",
}
# Keep it running
service { "mysqld":
ensure => "running",
hasstatus => true,
require => [ Package["mysql-server"], File[$mysqldirs], ]
}
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
You need to add a require to the service for the config files you are managing. I find the best way to do that is put all the config files in a config subclass and then require that in in the service. On 10 October 2012 01:02, Tom <tom@t0mb.net> 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: > > 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. > > 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. > > 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! > > Many thanks. Tom. > > > # List of directories we''re going to use with MySQL > $mysqldirs = [ "/home/data", "/home/logs", "/home/mysqltmp", ] > > # Set SELinux contexts > define add_selinux_context ($context = "mysqld_db_t") { > file { $name: > ensure => "directory", > owner => "mysql", > group => "mysql", > seltype => "mysqld_db_t", > selinux_ignore_defaults => "true", > recurse => "true", > require => Package["mysql-server"], > notify => [ Exec["add_file_context_${context}_${name}"], > Exec["set_file_context_${context}_${name}"], ], > } > > # Set the default file_context regex for the path > exec { "add_file_context_${context}_${name}": > command => "semanage fcontext -a -t ${context} \"${name}(/.*)?\"", > unless => "semanage fcontext -l | grep ''^${name}(/.*)?:${context}:''", > require => [ Package["policycoreutils-python"], File[$name], ], > refreshonly => "true", > } > > # Reset the file_context using restorecon > exec { "set_file_context_${context}_${name}": > command => "restorecon -R ${name}", > unless => "ls -d --scontext ${name} | awk -F: ''{print \$3}'' | grep > \"${context}\"", > require => File["$name"], > refreshonly => "true", > } > } > > add_selinux_context { $mysqldirs: > context => "mysqld_db_t", > } > > # Keep it running > service { "mysqld": > ensure => "running", > hasstatus => true, > require => [ Package["mysql-server"], File[$mysqldirs], ] > } > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Hi, Thanks for the response. Really, I think the way I''m approaching this is thinking about starting mysqld under the right selinux user context so that it doesn''t label its own files incorrectly. Every time a database or table is created, MySQL will be creating it under the wrong user context, and selinux will then go and reset it back. I think maybe a wrapper script using runcon which invokes the mysqld service under the correct context is going to be the way to go. Really though, I''d hoped that puppet had some kind of provision for starting services with the correct user context! Just wondering if anyone else has had the same issue in the past, or do they just ignore all those seluser notifications? :-) Many thanks. Tom. On 10/10/12 01:50, Peter Brown wrote:> You need to add a require to the service for the config files you are managing. > I find the best way to do that is put all the config files in a config > subclass and then require that in in the service. > > > On 10 October 2012 01:02, Tom<tom@t0mb.net> 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: >> >> 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. >> >> 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. >> >> 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! >> >> Many thanks. Tom. >> >> >> # List of directories we''re going to use with MySQL >> $mysqldirs = [ "/home/data", "/home/logs", "/home/mysqltmp", ] >> >> # Set SELinux contexts >> define add_selinux_context ($context = "mysqld_db_t") { >> file { $name: >> ensure => "directory", >> owner => "mysql", >> group => "mysql", >> seltype => "mysqld_db_t", >> selinux_ignore_defaults => "true", >> recurse => "true", >> require => Package["mysql-server"], >> notify => [ Exec["add_file_context_${context}_${name}"], >> Exec["set_file_context_${context}_${name}"], ], >> } >> >> # Set the default file_context regex for the path >> exec { "add_file_context_${context}_${name}": >> command => "semanage fcontext -a -t ${context} \"${name}(/.*)?\"", >> unless => "semanage fcontext -l | grep ''^${name}(/.*)?:${context}:''", >> require => [ Package["policycoreutils-python"], File[$name], ], >> refreshonly => "true", >> } >> >> # Reset the file_context using restorecon >> exec { "set_file_context_${context}_${name}": >> command => "restorecon -R ${name}", >> unless => "ls -d --scontext ${name} | awk -F: ''{print \$3}'' | grep >> \"${context}\"", >> require => File["$name"], >> refreshonly => "true", >> } >> } >> >> add_selinux_context { $mysqldirs: >> context => "mysqld_db_t", >> } >> >> # Keep it running >> service { "mysqld": >> ensure => "running", >> hasstatus => true, >> require => [ Package["mysql-server"], File[$mysqldirs], ] >> } >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Puppet Users" group. >> To post to this group, send email to puppet-users@googlegroups.com. >> To unsubscribe from this group, send email to >> puppet-users+unsubscribe@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/puppet-users?hl=en. >>-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Well, I''ve decided on a very simple way of doing this,
# Keep it running
service { "mysqld":
ensure => "running",
start => "runcon -u system_u /etc/init.d/mysqld start",
hasrestart => "false",
require => [ Package["mysql-server"], File[$mysqldirs], ],
}
so, it starts under the correct selinux user context, and then using
restart on the init script is disabled so that it makes use of the start
command when doing a restart.
Not sure if this would be something that would make a good resource flag?
Many thanks. Tom.
On 10/10/12 07:55, Tom wrote:> Hi,
>
> Thanks for the response. Really, I think the way I''m approaching
this
> is thinking about starting mysqld under the right selinux user context
> so that it doesn''t label its own files incorrectly. Every time a
> database or table is created, MySQL will be creating it under the
> wrong user context, and selinux will then go and reset it back.
>
> I think maybe a wrapper script using runcon which invokes the mysqld
> service under the correct context is going to be the way to go.
> Really though, I''d hoped that puppet had some kind of provision
for
> starting services with the correct user context!
>
> Just wondering if anyone else has had the same issue in the past, or
> do they just ignore all those seluser notifications? :-)
>
> Many thanks. Tom.
>
>
>
> On 10/10/12 01:50, Peter Brown wrote:
>> You need to add a require to the service for the config files you are
>> managing.
>> I find the best way to do that is put all the config files in a config
>> subclass and then require that in in the service.
>>
>>
>> On 10 October 2012 01:02, Tom<tom@t0mb.net> 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:
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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!
>>>
>>> Many thanks. Tom.
>>>
>>>
>>> # List of directories we''re going to use with MySQL
>>> $mysqldirs = [ "/home/data", "/home/logs",
"/home/mysqltmp", ]
>>>
>>> # Set SELinux contexts
>>> define add_selinux_context ($context = "mysqld_db_t")
{
>>> file { $name:
>>> ensure => "directory",
>>> owner => "mysql",
>>> group => "mysql",
>>> seltype => "mysqld_db_t",
>>> selinux_ignore_defaults => "true",
>>> recurse => "true",
>>> require => Package["mysql-server"],
>>> notify => [
Exec["add_file_context_${context}_${name}"],
>>> Exec["set_file_context_${context}_${name}"], ],
>>> }
>>>
>>> # Set the default file_context regex for the path
>>> exec { "add_file_context_${context}_${name}":
>>> command => "semanage fcontext -a -t ${context}
>>> \"${name}(/.*)?\"",
>>> unless => "semanage fcontext -l | grep
>>> ''^${name}(/.*)?:${context}:''",
>>> require => [
Package["policycoreutils-python"], File[$name], ],
>>> refreshonly => "true",
>>> }
>>>
>>> # Reset the file_context using restorecon
>>> exec { "set_file_context_${context}_${name}":
>>> command => "restorecon -R ${name}",
>>> unless => "ls -d --scontext ${name} | awk -F:
''{print \$3}''
>>> | grep
>>> \"${context}\"",
>>> require => File["$name"],
>>> refreshonly => "true",
>>> }
>>> }
>>>
>>> add_selinux_context { $mysqldirs:
>>> context => "mysqld_db_t",
>>> }
>>>
>>> # Keep it running
>>> service { "mysqld":
>>> ensure => "running",
>>> hasstatus => true,
>>> require => [ Package["mysql-server"],
File[$mysqldirs], ]
>>> }
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups
>>> "Puppet Users" group.
>>> To post to this group, send email to puppet-users@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> puppet-users+unsubscribe@googlegroups.com.
>>> For more options, visit this group at
>>> http://groups.google.com/group/puppet-users?hl=en.
>>>
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Tom, It seems like having that as a parameter in the service type might be a good idea worthy of at least some further discussion. Want to open a feature request in Redmine to track it? I might (eventually) take a stab at adding support for it. Sean On Wed, 2012-10-10 at 09:01 +0100, Tom wrote:> Well, I''ve decided on a very simple way of doing this, > > # Keep it running > service { "mysqld": > ensure => "running", > start => "runcon -u system_u /etc/init.d/mysqld start", > hasrestart => "false", > require => [ Package["mysql-server"], File[$mysqldirs], ], > } > > so, it starts under the correct selinux user context, and then using > restart on the init script is disabled so that it makes use of the start > command when doing a restart. > > Not sure if this would be something that would make a good resource flag? > > Many thanks. Tom. > > > > On 10/10/12 07:55, Tom wrote: > > Hi, > > > > Thanks for the response. Really, I think the way I''m approaching this > > is thinking about starting mysqld under the right selinux user context > > so that it doesn''t label its own files incorrectly. Every time a > > database or table is created, MySQL will be creating it under the > > wrong user context, and selinux will then go and reset it back. > > > > I think maybe a wrapper script using runcon which invokes the mysqld > > service under the correct context is going to be the way to go. > > Really though, I''d hoped that puppet had some kind of provision for > > starting services with the correct user context! > > > > Just wondering if anyone else has had the same issue in the past, or > > do they just ignore all those seluser notifications? :-) > > > > Many thanks. Tom. > > > > > > > > On 10/10/12 01:50, Peter Brown wrote: > >> You need to add a require to the service for the config files you are > >> managing. > >> I find the best way to do that is put all the config files in a config > >> subclass and then require that in in the service. > >> > >> > >> On 10 October 2012 01:02, Tom<tom@t0mb.net> 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: > >>> > >>> 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. > >>> > >>> 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. > >>> > >>> 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! > >>> > >>> Many thanks. Tom. > >>> > >>> > >>> # List of directories we''re going to use with MySQL > >>> $mysqldirs = [ "/home/data", "/home/logs", "/home/mysqltmp", ] > >>> > >>> # Set SELinux contexts > >>> define add_selinux_context ($context = "mysqld_db_t") { > >>> file { $name: > >>> ensure => "directory", > >>> owner => "mysql", > >>> group => "mysql", > >>> seltype => "mysqld_db_t", > >>> selinux_ignore_defaults => "true", > >>> recurse => "true", > >>> require => Package["mysql-server"], > >>> notify => [ Exec["add_file_context_${context}_${name}"], > >>> Exec["set_file_context_${context}_${name}"], ], > >>> } > >>> > >>> # Set the default file_context regex for the path > >>> exec { "add_file_context_${context}_${name}": > >>> command => "semanage fcontext -a -t ${context} > >>> \"${name}(/.*)?\"", > >>> unless => "semanage fcontext -l | grep > >>> ''^${name}(/.*)?:${context}:''", > >>> require => [ Package["policycoreutils-python"], File[$name], ], > >>> refreshonly => "true", > >>> } > >>> > >>> # Reset the file_context using restorecon > >>> exec { "set_file_context_${context}_${name}": > >>> command => "restorecon -R ${name}", > >>> unless => "ls -d --scontext ${name} | awk -F: ''{print \$3}'' > >>> | grep > >>> \"${context}\"", > >>> require => File["$name"], > >>> refreshonly => "true", > >>> } > >>> } > >>> > >>> add_selinux_context { $mysqldirs: > >>> context => "mysqld_db_t", > >>> } > >>> > >>> # Keep it running > >>> service { "mysqld": > >>> ensure => "running", > >>> hasstatus => true, > >>> require => [ Package["mysql-server"], File[$mysqldirs], ] > >>> } > >>> > >>> -- > >>> You received this message because you are subscribed to the Google > >>> Groups > >>> "Puppet Users" group. > >>> To post to this group, send email to puppet-users@googlegroups.com. > >>> To unsubscribe from this group, send email to > >>> puppet-users+unsubscribe@googlegroups.com. > >>> For more options, visit this group at > >>> http://groups.google.com/group/puppet-users?hl=en. > >>> > > >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
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. 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).> > 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. 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 puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Wednesday, October 10, 2012 7:08:21 AM UTC-5, Sean Millichamp wrote:> > Tom, > > It seems like having that as a parameter in the service type might be a > good idea worthy of at least some further discussion."[T]hat" refers to an SELinux context in which the service management commands are supposed to be executed?> Want to open a > feature request in Redmine to track it? I might (eventually) take a stab > at adding support for it. > >As you might infer from my other response, I think that''s altogether the wrong approach. Puppet should not provide such a parameter, because it invites users to misconfigure their systems (by using the proposed parameter as a workaround). Services'' configuration and the system tools should control services'' runtime parameters, including their SELinux context. Otherwise, the service cannot be started properly during system initialization, and it can easily be (re)started incorrectly during manual administration. 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/-/EpH0O46rKWQJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
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 puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscribe@googlegroups.com. > 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 puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Seemingly Similar Threads
- selinux-policy update resets /etc/selinux/targeted/contexts/files/file_contexts?
- Moving Mysql data directory denied by selinux?
- Unable to apply mysqld_db_t to mysql directory
- Unable to apply mysqld_db_t to mysql directory
- Unable to apply mysqld_db_t to mysql directory