Bug 240005

Created attachment 154631 [details]
audit_log

What is /var/run/dmeventd-client?

best to ask the lvm guys...

/var/run/dmeventd-client (and dmeventd-server) is named pipe which use dmeventd
to communicate with clients (spec. for misc. mirror conversions and monitoring).
So lvm2 commands (through libdevmapper libraries) communicate with this daemon.

Btw. isn't for selinux policy better to have these files in separate directory ?
Is there any change in device-mapper needed to enable function in enforcing mode ?

Hi, 
I encountered the same problem trying to start monitoring a VG with a mirrored
volume. 
The command 
vgchange --monitor y vg_mirror 
(which is internally lauched also by /etc/init.d/lvm2-monitor service)
tries to start dmeventd but selinux blocks it while trying to write the pipe
/var/run/dmeventd-client.
I tried to create the needed pipes by hand: 

[root@bootsrv ~]# ls -laZ /var/run/dme*
prw-------  root root root:object_r:lvm_var_run_t      /var/run/dmeventd-client
-rw-------  root root root:object_r:lvm_var_run_t      /var/run/dmeventd.pid
prw-------  root root root:object_r:lvm_var_run_t      /var/run/dmeventd-server

and assigned that context after some trials and tests reading selinux messages
through sealert (as suggested in /var/log/messages).

The command still fails: 

[root@bootsrv ~]# vgchange --monitor y vg_mirror
Child exited with code 6
  Unable to start dmeventd.
Child exited with code 6
  Unable to start dmeventd.
  vg_mirror-mirrored_lv: event registration failed: No such process
  vg_mirror/mirrored_lv: mirror segment monitoring function failed.
  4 logical volume(s) in volume group "vg_mirror" monitored

now the problem is slightly different (from /var/log/messages): 
dmeventd[4252]: Unable to set correct file permissions on /var/run/dmeventd-client
SELinux is preventing /usr/sbin/lvm (lvm_t) "getattr" to
/var/run/dmeventd-client (lvm_var_run_t).
SELinux is preventing /sbin/dmeventd (lvm_t) "getattr" to
/var/run/dmeventd-client (lvm_var_run_t).
SELinux is preventing /sbin/dmeventd (lvm_t) "getattr" to
/var/run/dmeventd-server (lvm_var_run_t).
SELinux is preventing /sbin/dmeventd (lvm_t) "setattr" to dmeventd-client
(lvm_var_run_t).
SELinux is preventing /usr/sbin/lvm (lvm_t) "getattr" to
/var/run/dmeventd-client (lvm_var_run_t).
SELinux is preventing /sbin/dmeventd (lvm_t) "getattr" to
/var/run/dmeventd-client (lvm_var_run_t).
SELinux is preventing /sbin/dmeventd (lvm_t) "getattr" to
/var/run/dmeventd-server (lvm_var_run_t).
SELinux is preventing /sbin/dmeventd (lvm_t) "setattr" to dmeventd-client
(lvm_var_run_t).

Maybe I set the wrong context for the pipes? 

I also tried to use audit2allow to create a local policy but I had no luck: 

[root@bootsrv ~]# cat /var/log/audit/audit.log | audit2allow > /tmp/local.te
[root@bootsrv ~]# cat /tmp/local.te


#============= lvm_t ==============
allow lvm_t lvm_var_run_t:fifo_file { getattr setattr };
[root@bootsrv ~]# checkmodule -M -m -o /tmp/local.mod /tmp/local.te
checkmodule:  loading policy configuration from /tmp/local.te
(unknown source)::ERROR 'syntax error' at token 'allow' on line 4:
allow lvm_t lvm_var_run_t:fifo_file { getattr setattr };

Any clue? 
Thanks. 

cat /var/log/audit/audit.log | audit2allow -M mylvm
semodule -i mylvm.pp

will create and load a policy module.

Fixed in selinux-policy-2.4.6-126.el5	

Although I am not sure this will make U2

Hi, 
I eventually succeded in starting dmeventd, this is the policy applied: 

#============= lvm_t ==============
allow lvm_t lvm_var_run_t:fifo_file { write read getattr setattr lock };

Please note that type lvm_var_run_t is the type I set by hand on the pipes, I
don't know wether it's the right one. 

checkmodule keeps complaining about 'syntax error', but it worked using 
audit2allow -M followed by semodule -i, as you suggested. 

Thanks a lot. 
Bye

Good.

Those changes are all in selinux-policy-2.4.6-126.el5	

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 the 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-2008-0081.html