Does cmirrord have kerberos support?  Or did someone add selinux smarts to it?

cmirrord does not perform any kerberos actions.

I haven't added any selinux-related code to it.

Well it must be a library that it is calling.

SELinux does not lie.    :^)

ldd /usr/sbin/cmirrord  | grep devmap
	libdevmapper.so.1.02 => /lib64/libdevmapper.so.1.02 (0x0000003437800000

nm -D /lib64/libdevmapper.so.1.02  | grep setfscreate
                 U setfscreatecon


Does cmirrord create devices in /dev?

It used to, but this is how it looks now:

        // LOG_DBG("Creating /dev/mapper/%d-%d", major, minor);
        // sprintf(path_rtn, "/dev/mapper/%d-%d", major, minor);
        // r = mknod(path_rtn, S_IFBLK | S_IRUSR | S_IWUSR, MKDEV(major, minor));

LVM/device-mapper is responsible for creating the devices.

I don't have a rhel6 box available right now, but I think I use the device-mapper library only for its list and bitop macros.  If I can get a rhel6 box and compile the binaries without stripping them, I could do a 'nm -o cmirrord ...' to find any symbols used.

So the library will do all of that for you.

Miroslav I think we are going to need to add

allow cmirrord_t self:process setfscreate;
storage_create_fixed_disk_dev(cmirrord_t)
seutil_read_file_contexts(cmirrord_t)

Jonathan,
does it work for you if you add the following local policy

# cat mypol.te
policy_module(mypol,1.0)

require{
 type cmirrord_t;
}

allow cmirrord_t self:process setfscreate;
storage_create_fixed_disk_dev(cmirrord_t)
seutil_read_file_contexts(cmirrord_t)


And execute

# make -f /usr/share/selinux/devel/Makefile
# semodule -i mypol.pp

That's a question for the bug filer, I think.

This is all I see when executing what's in comment #7.

Feb 15 13:59:44 grant-02 dbus: avc:  received policyload notice (seqno=2)
Feb 15 13:59:44 grant-02 dbus: [system] Reloaded configuration
Feb 15 13:59:44 grant-02 kernel: type=1403 audit(1297799984.702:4): policy loaded auid=0 ses=1

So cmirrord works with these rules.

Easy to reproduce without local policy mentioned in comment#7:

----
time->Wed Feb 16 03:42:26 2011
type=SYSCALL msg=audit(1297845746.271:13): arch=c000003e syscall=1 success=no exit=-13 a0=4 a1=0 a2=0 a3=7fffb2341340 items=0 ppid=9410 pid=9411 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="cmirrord" exe="/usr/sbin/cmirrord" subj=unconfined_u:system_r:cmirrord_t:s0 key=(null)
type=AVC msg=audit(1297845746.271:13): avc:  denied  { setfscreate } for  pid=9411 comm="cmirrord" scontext=unconfined_u:system_r:cmirrord_t:s0 tcontext=unconfined_u:system_r:cmirrord_t:s0 tclass=process
----

Fixed in selinux-policy-3.7.19-71.el6

Seeing a different error now:

[root@taft-01 ~]# service cmirrord start
Starting cmirrord: Failed to create lockfile
Process already running?
                                                           [FAILED]


type=AVC msg=audit(1298063220.345:44): avc:  denied  { create } for  pid=2328 comm="cmirrord" name="cmirrord.pid" scontext=unconfined_u:system_r:cmirrord_t:s0 tcontext=system_u:object_r:cmirrord_var_run_t:s0 tclass=file
type=SYSCALL msg=audit(1298063220.345:44): arch=c000003e syscall=2 success=no exit=-13 a0=417208 a1=41 a2=1a4 a3=6165726373662f72 items=0 ppid=2327 pid=2328 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=2 comm="cmirrord" exe="/usr/sbin/cmirrord" subj=unconfined_u:system_r:cmirrord_t:s0 key=(null)

This is with the latest policy:
selinux-policy-3.7.19-71.el6.noarch

Since the service is running as 

unconfined_u:system_r:cmirrord_t:s0

in stead of 

system_u:system_r:cmirrord_t:s0

The creation of the file is failing.  If you had run this application from init on boot it would have worked.  When you restarted it, it ended up with your user componant.

Miroslav you will need.


domain_obj_id_change_exemption(cmirrord_t)


If you wanted to restart it with system_u, you could execute

run_init service cmirrord restart

Fixed in selinux-policy-3.7.19-72.el6

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0526.html