Red Hat Bugzilla – Bug 1044151
With SeLinux, ports can be labelled per range. setup-ds.pl or setup-ds-admin.pl fail to detect already ranged labelled ports
Last modified: 2015-03-05 04:30:07 EST
This bug is created as a clone of upstream ticket: https://fedorahosted.org/389/ticket/47433 With SeLinux it is possible to label ports per range: semanage port -a -t ldap_port_t -p tcp 1389-1391 If we want to create an instance (setup-ds.pl or setup-ds-admin.pl) with port 1390 for example, the script checks if the port has the 'ldap_port_t' label (using 'semanage port -l). But the port being covered by a range rather being present in the ports list, the script fails to detect that the port is correctly labelled. Then it relabel it, that takes a long time. This could be fixed by something like: diff /usr/lib64/dirsrv/perl/DSCreate.pm ./DSCreate.pm 1010,1013c1010,1023 < if ($inf->{slapd}->{ServerPort} == $labeledport) { < $need_label = 0; < last; < } --- > if (index($labeledport, "-") == -1) { > # this is not a range > if ($inf->{slapd}->{ServerPort} == $labeledport) { > $need_label = 0; > last; > } > } else { > # this is a range > my @range = split(/-/, $labeledport); > if ((@range[0] <= $inf->{slapd}->{ServerPort}) && ($inf->{slapd}->{ServerPort} <= @range[1])) { > $need_label = 0; > last; > } > }
I use setup-ds.pl with -f option specifying file with default answers. ServerPort is 1390 [1] Port is not labeled: 15 sec $ sudo semanage port -l | awk '/ldap/ && /tcp/' ldap_port_t tcp 389, 636, 3268, 7389 $ time sudo setup-ds.pl -s -f answers.inf &> /dev/null real 0m15.013s user 0m10.477s sys 0m0.638s [2] Port is already labeled: 4 sec $ sudo semanage port -a 1390 -p tcp $ sudo semanage port -l | awk '/ldap/ && /tcp/' ldap_port_t tcp 1390, 389, 636, 3268, 7389 $ time sudo setup-ds.pl -s -f answers.inf &> /dev/null real 0m4.067s user 0m0.512s sys 0m0.102s [3] Port is already labeled using range: 4 sec $ sudo semanage port -a -t ldap_port_t -p tcp 1389-1391 $ sudo semanage port -l | awk '/ldap/ && /tcp/' ldap_port_t tcp 1389-1391, 389, 636, 3268, 7389 $ time sudo setup-ds.pl -s -f answers.inf &> /dev/null real 0m4.155s user 0m0.510s sys 0m0.110s [2] and [3] take the same amount of time -> relabeling is not happening. Hence marking as VERIFIED.
Forgot to mention DS version: $ rpm -qa | grep 389 389-ds-base-1.3.3.1-9.el7.x86_64 389-ds-base-debuginfo-1.3.3.1-9.el7.x86_64 389-ds-base-libs-1.3.3.1-9.el7.x86_64
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2015-0416.html