After getting bitten many times by our config mgmt system not reloading
shorewall (4.0.7) after a configuration change, I''m adding
shorewall''s state
to the monitoring system, which executes commands as the user
''nrpe'', and
not as root.
The monitoring script checks shorewall''s status from
/var/lib/shorewall/state. However, I found that on some systems, that
file''s perms are 0644, where on others, it is 0600. It appears that
this is
unpredictable, as it depends on the order in which shorewall stop and start
commands were executed in the past. Here''s a script that shows
what''s
happening:
[root@mon0 ~]# cd /var/lib/shorewall
[root@mon0 shorewall]# ls -l state
4 -rw-r--r-- 1 root root 39 Feb 26 16:01 state
[root@mon0 shorewall]# rm -f state
[root@mon0 shorewall]# service shorewall stop >/dev/null
[root@mon0 shorewall]# ls -l state
4 -rw------- 1 root root 39 Feb 26 16:01 state
[root@mon0 shorewall]# rm -f state
[root@mon0 shorewall]# service shorewall start >/dev/null
[root@mon0 shorewall]# ls -l state
4 -rw-r--r-- 1 root root 39 Feb 26 16:02 state
This can be tracked down in the shorewall scripts quite easily.
''shorewall
stop'' calls the /usr/share/shorewall/firewall script, which then calls
''do_initialize()'' from lib.config, setting the umask to 077.
The state file
is written by ''set_state()'' in lib.base.
On a ''shorewall start'', however, the lib.config script
isn''t used, and no
umask is ever set. Instead of the firewall script, the
/var/lib/shorewall/.start script calls its own ''set_state()''
function, which
the comments indicate is imported from the lib.base file.
The result is that the permissions will be set depending on whether the
/var/lib/shorewall/state file was first created by shorewall stop or
shorewall start.
Thanks
John
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
John Morris wrote:> After getting bitten many times by our config mgmt system not reloading > shorewall (4.0.7) after a configuration change, I''m adding shorewall''s > state to the monitoring system, which executes commands as the user > ''nrpe'', and not as root. > > The monitoring script checks shorewall''s status from > /var/lib/shorewall/state. However, I found that on some systems, that > file''s perms are 0644, where on others, it is 0600. It appears that > this is unpredictable, as it depends on the order in which shorewall > stop and start commands were executed in the past. Here''s a script that > shows what''s happening: > > [root@mon0 ~]# cd /var/lib/shorewall > [root@mon0 shorewall]# ls -l state > 4 -rw-r--r-- 1 root root 39 Feb 26 16:01 state > [root@mon0 shorewall]# rm -f state > [root@mon0 shorewall]# service shorewall stop >/dev/null > [root@mon0 shorewall]# ls -l state > 4 -rw------- 1 root root 39 Feb 26 16:01 state > [root@mon0 shorewall]# rm -f state > [root@mon0 shorewall]# service shorewall start >/dev/null > [root@mon0 shorewall]# ls -l state > 4 -rw-r--r-- 1 root root 39 Feb 26 16:02 state > > This can be tracked down in the shorewall scripts quite easily. > ''shorewall stop'' calls the /usr/share/shorewall/firewall script, which > then calls ''do_initialize()'' from lib.config, setting the umask to 077. > The state file is written by ''set_state()'' in lib.base. > > On a ''shorewall start'', however, the lib.config script isn''t used, and > no umask is ever set. Instead of the firewall script, the > /var/lib/shorewall/.start script calls its own ''set_state()'' function, > which the comments indicate is imported from the lib.base file. > > The result is that the permissions will be set depending on whether the > /var/lib/shorewall/state file was first created by shorewall stop or > shorewall start. >If we change this, we will likely call umask in all cases. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H
Tom Eastep wrote:> John Morris wrote: >> After getting bitten many times by our config mgmt system not reloading >> shorewall (4.0.7) after a configuration change, I''m adding shorewall''s >> state to the monitoring system, which executes commands as the user >> ''nrpe'', and not as root. >> >> The monitoring script checks shorewall''s status from >> /var/lib/shorewall/state. However, I found that on some systems, that >> file''s perms are 0644, where on others, it is 0600. It appears that >> this is unpredictable, as it depends on the order in which shorewall >> stop and start commands were executed in the past. Here''s a script that >> shows what''s happening: >> >> [root@mon0 ~]# cd /var/lib/shorewall >> [root@mon0 shorewall]# ls -l state >> 4 -rw-r--r-- 1 root root 39 Feb 26 16:01 state >> [root@mon0 shorewall]# rm -f state >> [root@mon0 shorewall]# service shorewall stop >/dev/null >> [root@mon0 shorewall]# ls -l state >> 4 -rw------- 1 root root 39 Feb 26 16:01 state >> [root@mon0 shorewall]# rm -f state >> [root@mon0 shorewall]# service shorewall start >/dev/null >> [root@mon0 shorewall]# ls -l state >> 4 -rw-r--r-- 1 root root 39 Feb 26 16:02 state >> >> This can be tracked down in the shorewall scripts quite easily. >> ''shorewall stop'' calls the /usr/share/shorewall/firewall script, which >> then calls ''do_initialize()'' from lib.config, setting the umask to 077. >> The state file is written by ''set_state()'' in lib.base. >> >> On a ''shorewall start'', however, the lib.config script isn''t used, and >> no umask is ever set. Instead of the firewall script, the >> /var/lib/shorewall/.start script calls its own ''set_state()'' function, >> which the comments indicate is imported from the lib.base file. >> >> The result is that the permissions will be set depending on whether the >> /var/lib/shorewall/state file was first created by shorewall stop or >> shorewall start. >> > > If we change this, we will likely call umask in all cases.So if you want the file to be world-readable, it would be a good idea to place ''chmod'' commands in /etc/shorewall/started and /etc/shorewall/stopped -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H
John Morris
2009-Feb-27 02:18 UTC
Re: /var/lib/shorewall/state permissions inconsistencies
> > >> The result is that the permissions will be set depending on whether the > >> /var/lib/shorewall/state file was first created by shorewall stop or > >> shorewall start. > >> > > > > If we change this, we will likely call umask in all cases. > > So if you want the file to be world-readable, it would be a good idea to > place ''chmod'' commands in /etc/shorewall/started and /etc/shorewall/stopped >I guessed this would be the answer. I''ll solve this problems using extension scripts, as you suggest. Thanks- John ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H