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
Summary: With SeLinux, ports can be labelled per range. setup-ds.pl or setup-ds-admin....
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base
Version: 7.0
Hardware: Unspecified
OS: Unspecified
medium
unspecified
Target Milestone: rc
: ---
Assignee: Rich Megginson
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-12-17 21:29 UTC by Nathan Kinder
Modified: 2015-03-05 09:30 UTC (History)
2 users (show)

Fixed In Version: 389-ds-base-1.3.3.1-1.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-03-05 09:30:07 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2015:0416 normal SHIPPED_LIVE Important: 389-ds-base security, bug fix, and enhancement update 2015-03-05 14:26:33 UTC

Description Nathan Kinder 2013-12-17 21:29:16 UTC
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;
>             }
>         }

Comment 3 Viktor Ashirov 2014-12-01 15:37:49 UTC
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.

Comment 4 Viktor Ashirov 2014-12-01 16:00:52 UTC
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

Comment 6 errata-xmlrpc 2015-03-05 09:30:07 UTC
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


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