Bug 145664 - "integer expression expected" on named startup
Summary: "integer expression expected" on named startup
Alias: None
Product: Fedora
Classification: Fedora
Component: bind   
(Show other bugs)
Version: 3
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jason Vas Dias
QA Contact:
: 147073 147824 149572 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2005-01-20 15:35 UTC by Warren Sturm
Modified: 2007-11-30 22:10 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-09-05 08:25:47 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
/etc/selinux/targeted/booleans per comment 1 (120 bytes, text/plain)
2005-01-21 03:18 UTC, Warren Sturm
no flags Details

Description Warren Sturm 2005-01-20 15:35:07 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041111 Firefox/1.0

Description of problem:
Just after up2date install of bind*-9.2.4-8_FC3

service named restart
Stopping named:                                            [  OK  ]
Starting named: /etc/init.d/named: line 49: [: : integer expression
/etc/init.d/named: line 51: [: : integer expression expected
                                                           [  OK  ]

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. service named stop
2. service named start

Actual Results:  service named restart
Stopping named:                                            [  OK  ]
Starting named: /etc/init.d/named: line 49: [: : integer expression
/etc/init.d/named: line 51: [: : integer expression expected
                                                           [  OK  ]

Expected Results:  service named restart
Stopping named:                                            [  OK  ]
Starting named:                                            [  OK  ]

Additional info:

Looks like it has something to do with the $named_write_master_zones
variable which is not set.

Comment 1 Jason Vas Dias 2005-01-20 15:46:12 UTC
What version of the 'selinux-policy-targeted' rpm do you have ?
 # rpm -q selinux-policy-targeted
This package must be installed whether selinux is enabled or not,
and will create a file called /etc/selinux/policy/targeted/booleans
which must contain a line like:
Please append the contents of your /etc/selinux/policy/targeted/booleans
file to this bug - thanks.

Comment 2 Jason Vas Dias 2005-01-20 15:50:07 UTC
It is possible if you installed a very early version of FC3 and then
upgraded that the 'selinux-policy-targeted' package would upgrade 
its /etc/selinux/policy/targeted/booleans file by creating a 
/etc/selinux/policy/targeted/booleans.rpmsave file - this would contain
the named_write_master_zones setting that you evidently lack .  Doing:
  # mv /etc/selinux/policy/targeted/booleans.rpmsave \
should fix the problem.

Comment 3 Jason Vas Dias 2005-01-20 15:51:13 UTC
That should have been:
  # mv /etc/selinux/policy/targeted/booleans.rpmnew \

Comment 4 Warren Sturm 2005-01-21 03:18:50 UTC
Created attachment 110039 [details]
/etc/selinux/targeted/booleans per comment 1

Comment 5 Warren Sturm 2005-01-21 03:22:54 UTC
Comment 1:  selinux-policy-targeted-1.17.30-2.72
My path is /etc/selinux/targeted/booleans.  There is only policy.18 in

Comment 2:  There was an rpmnew file in a couple of the subdirectories
that I have mv'd over the old ones.

Comment 6 Warren Sturm 2005-01-21 05:25:59 UTC
ok.  I think I found my problem.  The /etc/sysconfig/selinux file had
SELINUX set to disabled and SELINUXTYPE set to strict.  There was no
booleans file in the /et/selinux/strict directory.  I modified the
SELINUXTYPE to targeted and the error goes away.

Comment 7 Jason Vas Dias 2005-01-24 22:14:40 UTC
OK - I was under the impression that both strict and targetted policy
had 'named_write_master_zones' - it seems that strict does not.
This problem will be fixed in the next bind release, with this patch:

--- named.init.~1.20.~  2005-01-14 13:03:51.000000000 -0500
+++ named.init  2005-01-24 17:09:46.489128000 -0500
@@ -46,11 +46,13 @@
            .  /etc/selinux/config
            if [ "$SELINUXTYPE" != "" ] && [ -d
/etc/selinux/${SELINUXTYPE} ] && [ -e
/etc/selinux/${SELINUXTYPE}/booleans  ]; then
               . /etc/selinux/${SELINUXTYPE}/booleans
-              if [ "$named_write_master_zones" -eq 1 ] ; then
-                   /bin/chown -f --from=root:named named:named
-              elif [ "$named_write_master_zones" -eq 0 ] ; then
-                   /bin/chown -f --from=named:named root:named
-              fi;
+              if echo "$named_write_master_zones" | /bin/egrep -q
'^[0-9]+$'; then
+                  if [ "$named_write_master_zones" -eq 1 ] ; then
+                      /bin/chown -f --from=root:named named:named
+                  elif [ "$named_write_master_zones" -eq 0 ] ; then
+                      /bin/chown -f --from=named:named root:named
+                  fi;
+               fi;

Comment 8 Jason Vas Dias 2005-02-04 15:46:51 UTC
*** Bug 147073 has been marked as a duplicate of this bug. ***

Comment 9 Garrett Schure 2005-02-04 16:56:16 UTC
My expectation is that an SELINUX setting of "disabled" would
override, and should be tested for before checking

Man selinux:

   The SELINUX variable may be set to any one of 
   disabled, permissive, or enforcing to select one
   of these options. The disabled option completely
   disables the SELinux kernel and *application code*,

Comment 10 Jason Vas Dias 2005-02-04 17:08:56 UTC
The functionality in the /etc/init.d/named script has nothing to do
with whether SELinux is enabled or not. It is there to ensure that
if the user has enabled dynamic dns updates, then the $ROOTDIR/var/named
directory will have the right ownership to enable DDNS to succeed . 
If the user has not set the 'named_write_master_zones' boolean to 1, 
then DDNS is disabled; if set to 1, then the ownership of the 
$ROOTDIR/var/named directory must be named:named to allow DDNS updates
to succeed.

Comment 11 Garrett Schure 2005-02-05 01:37:26 UTC
Isn't the script making behavior decisions by reading
configuration settings out of an unintended policy file,
ignoring where the overall configuration says, very
specifically, that that policy, and any of its settings,
is not in effect?

It's an accidental test, whether the policy file happens
to exist in the right spot in the file system, not whether
the user intends and has specified the policy and its
settings to be implemented.

If you are reading SELinux configuration settings to make
decisions about behavior, you can't merely assert it has
nothing to do with whether SELinux is enabled.  

Comment 12 Jason Vas Dias 2005-02-07 17:26:34 UTC
OK, I'll fix this in the next version: if ${SELINUX} is unset or
"disabled", then if the 'ENABLE_DDNS' variable is set in 
/etc/sysconfig/named, the $ROOTDIR/var/named permissions will be
set accordingly.  

Comment 13 Jason Vas Dias 2005-02-25 19:55:58 UTC
*** Bug 149572 has been marked as a duplicate of this bug. ***

Comment 14 Jason Vas Dias 2005-02-25 19:57:52 UTC
This is now fixed in bind-9.2.5rc1-1 (FC3) / bind-9.3.1rc1-1 (FC4).

If SELinux is not disabled, the setting of 'named_write_master_zones'
will determine whether $ROOTDIR/var/named has ownership named:named
(named_write_master_zones=1) or root:named (named_write_master_zones=0).

If SELinux is disabled, if the variable 'ENABLE_ZONE_WRITE' is 
set to 'yes'/'1' in /etc/sysconfig/named, then the ownership 
of  $ROOTDIR/var/named is set to named:named; if  'ENABLE_ZONE_WRITE'
is set to 'no'/'0', the ownership of  $ROOTDIR/var/named is set to
root:named; if ENABLE_ZONE_WRITE is not set, the ownership of
$ROOTDIR/var/named is unchanged. 

This automatic setting of the $ROOTDIR/var/named was to minimise
the impact of the change of ownership of $ROOTDIR/var/named to
root:root to counter known security vulnerabilities as mandated 
by our security response team.

Now, with SELinux, DDNS and slave zone writes can be enabled through
use of the system-config-security GUI only, without extra steps 
having to be taken by the administrator to set the ownership of the
/var/named directory.

Comment 15 Jason Vas Dias 2005-02-25 19:58:16 UTC
*** Bug 147824 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.