This looks like whoever created the sock_file, created it with the wrong context were you running ldap as unconfined_t rather then from the service script?

I was running ldap (dirsrv/389ds) from the IPA service script (from ipa-server).

The friendly people in #freeipa on FreeNode had this to say about this bz:

<nkinder> richm: I thought the ldapi file was supposed to be labeled as dirsrv_var_run_t
* SEJeff|away is now known as SEJeff
<richm> nkinder: yeah - weird
<nkinder> richm: AVC shows it's just plain var_run_t, so we're not allowed to unlink it.
<nkinder> richm, rthomson: I bet it was a blanked relabel that changed the ldapi socket from dirsrv_var_run_t to var_run_t when selinux-policy was upgraded
<rthomson> nkinder: thanks for the analysis
<nkinder> actually, it looks like it should be slapd_var_run_t
<nkinder> rthomson: what does "ls -lZ" show for the socket file now?
<rthomson> unconfined_u:object_r:dirsrv_var_run_t:s0
<nkinder> rthomson: ok, so it got mislabeled somehow to var_run_t
<nkinder> rthomson: RHEL6, right?
<rthomson> yes
<richm> nkinder: removing the file and letting the directory server recreate it will make sure it is created as dirsrv_var_run_t?
<nkinder> rthomson: looks like a bug in selinux-policy that was fixed in fedora at some time
<nkinder> richm: yes
<nkinder> richm: the problem is that "semanage fcontext -l" on RHEL6 shows that there is no fcontext rule to label /var/run/slapd.* as anything
<nkinder> richm: this means restorecon will change the ldapi socket to the default for the directory, which is var_run_t
<rthomson> You guys rock!
<nkinder> richm: on F16, I see that there is a fcontext rule for /var/run/slapd.*
<richm> ok - so yeah, they must have missed backporting that from fedora to rhel
<nkinder> richm: yep
<nkinder> so restorecon from the selinux-policy upgrade nuked our label, and ns-slapd wasn't allowed to do anything with it anymore
<nkinder> we use a transition when we create the file, so ns-slapd will create it with the proper context if it doesn't already exist

Looks like we have it commented out on RHEL6 and on in Fedora.


#/var/run/slapd.*	-s	gen_context(system_u:object_r:slapd_var_run_t,s0)
versus

+/var/run/slapd.*	-s	gen_context(system_u:object_r:slapd_var_run_t,s0)

I see in RHEL6

#/var/run/slapd.*   -s  gen_context(system_u:object_r:slapd_var_run_t,s0)

I guess there was a reason for this.

AFAIK we wanted to have it with dirsrv_var_run_t. 

Will we need to change it back to slapd_var_run_t?

I am not sure why it is commented out in RHEL6.  As far as the dirsrv vs slapd label, I'm not really sure.  I believe the policy I originally wrote used the dirsrv_var_run_t label (before putting it in selinux-policy package).  I'm guessing the slapd_var_run_t label already existed for OpenLDAP, so it was reused.  As long as we have rules like the following for the label you use, it shouldn't matter which label it is:

-------------------------------------------------------------------------
# pid files
manage_files_pattern(dirsrv_t, dirsrv_var_run_t, dirsrv_var_run_t)
files_pid_filetrans(dirsrv_t, dirsrv_var_run_t, { file sock_file })

# ldapi socket
manage_sock_files_pattern(dirsrv_t, dirsrv_var_run_t, dirsrv_var_run_t)
-------------------------------------------------------------------------

I think it should be fine to just do the same thing you are doing in Fedora.

One other thought around why the slapd_var_run_t label was used is that other policies might have rules that allow confined processes to connect to a slapd_var_run_t sock_file by using the ldap_stream_connect() macro.  This macro does not use grant any access to a dirsrv_var_run_t sock_file.

Yes ldap_stream_connect should probably be adjusted to allow you to connect to dirsrv.

Fixed in selinux-policy-3.7.19-142.el6

It looks as if the fcontext rule was added to label the socket file as slapd_var_run_t, but no rule was updated to allow dirsrv_t to manage a sock_file with that label.  Scott will add the AVC and semanage output from his test system.

Here are details from Scott's testing:

# rpm -q selinux-policy
selinux-policy-3.7.19-142.el6.noarch

# ipactl restart
Restarting Directory Service
Shutting down dirsrv: 
    PKI-IPA...[  OK  ]
    TESTRELM-COM...[  OK  ]
Starting dirsrv: 
    PKI-IPA...[  OK  ]
    TESTRELM-COM...[21/Mar/2012:15:32:03 -0400] createprlistensockets -
PR_Bind() on localhost file /var/run/slapd-TESTRELM-COM.socket failed: Netscape
Portable Runtime error -5982 (Local Network address is in use.)
[FAILED]
  *** Warning: 1 instance(s) failed to start
Failed to read data from Directory Service: Failed to get list of services to
probe status:
Directory Server is stopped
Shutting down
Shutting down dirsrv: 
    PKI-IPA...[  OK  ]
    TESTRELM-COM... server already stopped[FAILED]
  *** Error: 1 instance(s) unsuccessfully stopped[FAILED]

# ausearch -m AVC
----
time->Wed Mar 21 15:32:03 2012
type=SYSCALL msg=audit(1332358323.624:202): arch=c000003e syscall=87 success=no
exit=-13 a0=f68fd2 a1=f682f2 a2=45 a3=6b636f732e4d4f43 items=0 ppid=14688
pid=14689 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
tty=pts0 ses=10 comm="ns-slapd" exe="/usr/sbin/ns-slapd"
subj=unconfined_u:system_r:dirsrv_t:s0 key=(null)
type=AVC msg=audit(1332358323.624:202): avc:  denied  { unlink } for  pid=14689
comm="ns-slapd" name="slapd-TESTRELM-COM.socket" dev=dm-0 ino=1966792
scontext=unconfined_u:system_r:dirsrv_t:s0
tcontext=unconfined_u:object_r:slapd_var_run_t:s0 tclass=sock_file

# semanage fcontext -l | grep /var/run/slapd
/var/run/slapd.*                                   socket            
system_u:object_r:slapd_var_run_t:s0 
/var/run/slapd\.args                               regular file      
system_u:object_r:slapd_var_run_t:s0 
/var/run/slapd\.pid                                regular file      
system_u:object_r:slapd_var_run_t:s0

I just looked at the source for selinux-policy-3.7.19-142.el6, and I think a few changes are needed if you are going to use slapd_var_run_t for /var/run/slapd.* socket files. The dirsrv policy currently expects the socket file to be dirsrv_var_run_t (and I believe it will still create it that way at runtime due to it's transition rule).

Here is what I think it needed if you want to use slapd_var_run_t:

-----------------------------------------------------------------------
dirsrv local policy needs to add:
manage_sock_files_pattern(dirsrv_t, slapd_var_run_t, slapd_var_run_t)

dirsrv_manage_var_run() - needs to add:
allow $1 slapd_var_run_t:sock_file manage_file_perms;

dirsrv_stream_connect() - needs to add:
stream_connect_pattern($1, slapd_var_run_t, slapd_var_run_t, dirsrv_t)

ldap_stream_connect_dirsrv() - needs to add:
stream_connect_pattern($1, slapd_var_run_t, slapd_var_run_t, dirsrv_t)

-----------------------------------------------------------------------

Please note that a dirsrv_t process will still create /var/run/slapd.* files with a dirsrv_t label at runtime due to the transition rule, yet a restorecon will change the label to slapd_var_run_t.  This seems a bit inconsistent, but it should work as long as we are allowed to work with either label.

>Please note that a dirsrv_t process will still create /var/run/slapd.* files
>with a dirsrv_t label at runtime due to the transition rule, yet a restorecon
>will change the label to slapd_var_run_t.  This seems a bit inconsistent, but
>it should work as long as we are allowed to work with either label.

ok and now we know the reason why we had commented 

#/var/run/slapd.*   -s  gen_context(system_u:object_r:slapd_var_run_t,s0)

So you are saying this is not the same as we have in Fedora. Because I made things as we have in Fedora.


dirsrv_stream_connect()
ldap_stream_connect_dirsrv()

are not an issue because these interfaces are always called together.

Yes, this is broken in Fedora as well.  I just tested on F16 with selinux-policy-3.10.0-75.fc16.noarch, and the same problem exists.

Starting dirsrv creates the socket file with dirsrv_var_run_t:

-----------------------------------------------------------------------
[root@localhost ~]# systemctl start dirsrv.target
[root@localhost ~]# ps -ef | grep slapd
nobody   22917     1  1 08:50 ?        00:00:00 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-localhost -i /var/run/dirsrv/slapd-localhost.pid -w /var/run/dirsrv/slapd-localhost.startpid
root     22958 10724  0 08:50 pts/3    00:00:00 grep --color=auto slapd
[root@localhost ~]# ls -lZ /var/run/slapd-localhost.socket 
srw-rw-rw-. root root system_u:object_r:dirsrv_var_run_t:s0 /var/run/slapd-localhost.socket
-----------------------------------------------------------------------

Running restorecon changes the context of the socket file to slapd_var_run_t.  I ran this while ns-slapd was still up and running:

-----------------------------------------------------------------------
[root@localhost ~]# restorecon -v /var/run/slapd-localhost.socket
restorecon reset /run/slapd-localhost.socket context system_u:object_r:dirsrv_var_run_t:s0->system_u:object_r:slapd_var_run_t:s0
[root@localhost ~]# ls -lZ /var/run/slapd-localhost.socket 
srw-rw-rw-. root root system_u:object_r:slapd_var_run_t:s0 /var/run/slapd-localhost.socket
-----------------------------------------------------------------------

At this point, a restart of dirsrv will fail since dirsrv_t is not allowed to unlink the relabelled socket file:


-----------------------------------------------------------------------
[root@localhost ~]# systemctl restart dirsrv.target
[root@localhost ~]# ps -ef | grep slapd
root     22990 10724  0 08:51 pts/3    00:00:00 grep --color=auto slapd

type=AVC msg=audit(1332517857.460:332): avc:  denied  { unlink } for  pid=22980 comm="ns-slapd" name="slapd-localhost.socket" dev=tmpfs ino=506215 scontext=system_u:system_r:dirsrv_t:s0 tcontext=system_u:object_r:slapd_var_run_t:s0 tclass=sock_file
type=SYSCALL msg=audit(1332517857.460:332): arch=c000003e syscall=87 success=no exit=-13 a0=be40f2 a1=bf09cf a2=0 a3=b0140c items=0 ppid=1 pid=22980 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="ns-slapd" exe="/usr/sbin/ns-slapd" subj=system_u:system_r:dirsrv_t:s0 key=(null)
-----------------------------------------------------------------------

Ok, you want to have dirsrv the socket file with slapd_var_run_t for 

/var/run/slapd.* sockets.

right? 

But we have in the policy

manage_sock_files_pattern(dirsrv_t, dirsrv_var_run_t, dirsrv_var_run_t)
files_pid_filetrans(dirsrv_t, dirsrv_var_run_t, { file dir sock_file })

The problem is these sockets files are created by dirsrv. I would stay with dirsrv_var_run_t and make this working with this label.

(In reply to comment #19)
> The problem is these sockets files are created by dirsrv. I would stay with
> dirsrv_var_run_t and make this working with this label.

I am fine with this approach, as it is the least intrusive.

Which means if you stop all services and remove /var/run/slapd* sockets and then start all services everything should work. But just don't run restorecon on /var/run/slapd* sockets. I need to comment it as we had.

And this bug actually is not bug.

> Which means if you stop all services and remove /var/run/slapd* sockets and
> then start all services everything should work. But just don't run restorecon
> on /var/run/slapd* sockets. I need to comment it as we had.
> 
> And this bug actually is not bug.

Excuse my lack of understanding but does this mean that nothing is going to change and that every time I update selinux-policy, that Samba will lose it's connection to my LDAP server?

(In reply to comment #21)
> Which means if you stop all services and remove /var/run/slapd* sockets and
> then start all services everything should work. But just don't run restorecon
> on /var/run/slapd* sockets. I need to comment it as we had.
> 
> And this bug actually is not bug.

If you simply comment out the rule (like below), won't we still have a problem?

-----------------------------------------------------------------------
#/var/run/slapd.* -s gen_context(system_u:object_r:slapd_var_run_t,s0)
-----------------------------------------------------------------------

In this case, a restorecon will change /var/run/slapd.* socket files to
var_run_t, and ns-slapd (dirsrv_t) will not be allowed to delete it during a
restart.  We can't control when a restorecon will run, so this is a problem. 
Isn't the right approach to add a rule like this:

-----------------------------------------------------------------------
/var/run/slapd.* -s gen_context(system_u:object_r:dirsrv_var_run_t,s0)
-----------------------------------------------------------------------

Nathan,
yes I meant what you wrote

/var/run/slapd.* -s gen_context(system_u:object_r:dirsrv_var_run_t,s0)

I added changes to Fedora, backporting to RHEL6.3.

Do you know yet when that will make it into RHEL?   Or is it included in the 3.7.19-144 rev?

This is going to be in -145.el6 release tomorrow.

If it helps, here's the verification I did around the IPA testing related to this for bug 803054:

# ipactl status
Directory Service: RUNNING
KDC Service: RUNNING
KPASSWD Service: RUNNING
DNS Service: RUNNING
MEMCACHE Service: RUNNING
HTTP Service: RUNNING
CA Service: RUNNING

# restorecon /var/run/slapd-TESTRELM-COM.socket

# ls -lZ /var/run/slapd-TESTRELM-COM.socket
srw-rw-rw-. root root unconfined_u:object_r:slapd_var_run_t:s0 /var/run/slapd-TESTRELM-COM.socket

# rm /var/run/slapd-TESTRELM-COM.socket
rm: remove socket `/var/run/slapd-TESTRELM-COM.socket'? y

# ipactl start
Starting Directory Service
Starting dirsrv: 
    PKI-IPA...                                             [  OK  ]
    TESTRELM-COM...                                        [  OK  ]
Starting KDC Service
Starting Kerberos 5 KDC:                                   [  OK  ]
Starting KPASSWD Service
Starting Kerberos 5 Admin Server:                          [  OK  ]
Starting DNS Service
Starting named:                                            [  OK  ]
Starting MEMCACHE Service
Starting ipa_memcached:                                    [  OK  ]
Starting HTTP Service
Starting httpd: [Mon Apr 09 12:46:02 2012] [warn] worker ajp://localhost:9447/ already used by another worker
[Mon Apr 09 12:46:02 2012] [warn] worker ajp://localhost:9447/ already used by another worker
                                                           [  OK  ]
Starting CA Service
Starting pki-ca:                                           [  OK  ]

# ls -lZ /var/run/slapd-TESTRELM-COM.socket
srw-rw-rw-. root root unconfined_u:object_r:dirsrv_var_run_t:s0 /var/run/slapd-TESTRELM-COM.socket

# yum update selinux-policy
<snip>
Running Transaction
  Updating   : selinux-policy-3.7.19-145.el6.noarch                                                1/4 
  Updating   : selinux-policy-targeted-3.7.19-145.el6.noarch                                       2/4 
  Cleanup    : selinux-policy-targeted-3.7.19-142.el6.noarch                                       3/4 
  Cleanup    : selinux-policy-3.7.19-142.el6.noarch                                                4/4 
Installed products updated.


Updated:
  selinux-policy.noarch 0:3.7.19-145.el6                                                               

Dependency Updated:
  selinux-policy-targeted.noarch 0:3.7.19-145.el6                                                      

Complete!
</snip>

# ipactl status
Directory Service: RUNNING
KDC Service: RUNNING
KPASSWD Service: RUNNING
DNS Service: RUNNING
MEMCACHE Service: RUNNING
HTTP Service: RUNNING
CA Service: RUNNING
# ls -lZ /var/run/slapd-TESTRELM-COM.socket 
srw-rw-rw-. root root unconfined_u:object_r:dirsrv_var_run_t:s0 /var/run/slapd-TESTRELM-COM.socket

# restorecon /var/run/slapd-TESTRELM-COM.socket

# ls -lZ /var/run/slapd-TESTRELM-COM.socket 
srw-rw-rw-. root root unconfined_u:object_r:dirsrv_var_run_t:s0 /var/run/slapd-TESTRELM-COM.socket

# rpm -q selinux-policy
selinux-policy-3.7.19-145.el6.noarch

# bunzip2 -c /usr/share/selinux/targeted/dirsrv.pp.bz2 | strings | grep /var/run/slapd
/var/run/slapd.* -s system_u:object_r:dirsrv_var_run_t:s0

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.

http://rhn.redhat.com/errata/RHBA-2012-0780.html