Red Hat Bugzilla – Bug 430667
avc: denied { read } for comm="readahead" name=".tmp-253-0" dev=tmpfs
Last modified: 2008-05-21 11:59:34 EDT
Description of problem: Lots of avc denials found in fresh installation of RHEL5.2-Client-20080129.nightly Version-Release number of selected component (if applicable): selinux-policy-targeted-2.4.6-116.el5 / RHEL5.2-Client-20080129.nightly How reproducible: Always Steps to Reproduce: 1. Install RHEL5.2-Client-20080129.nightly 2. Reboot 3. dmesg |grep avc:\ *denied Actual results: Lots of messages of following type: avc: denied { read } for pid=1804 comm="readahead" name=".tmp-253-0" dev=tmpfs ino=3734 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=blk_file
There should not be .tmp-353-0 blk_files on /dev? This is either a udev/anaconda/fstools problem.
This is definitely not anaconda problem. Devices /dev/.tmp-253-* are being created by udevd whenever initscripts attempt to activate logical volumes present in the system. Reassigning to udev (although I'm not sure that's actually the right component). Version of udev: udev-095-14.12.el5
well, vol_id, scsi_id, etc. need temporary files
Is this something new? I have never seen these AVC messages before. Does udev end up renaming these temporary devices? If yes, it should use the context of the final name of the devices to label the correctly.
no, and no... not new and they are deleted afterwards IIRC
and readahead should not take /tmp into account, anyway
The thing is those devices are created in /dev directory with system_u:object_r:device_t label and certainly are not deleted afterwards.
Harald, are the .tmp-253-* device nodes supposed to be created in /dev directory and are they supposed to stay there or be deleted? If they're suuposed to be persistent, they should definitely be labeled with the correct context.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
> Harald, are the .tmp-253-* device nodes supposed to be created in /dev directory yes, sure... the only place which is writable > and are they supposed to stay there or be deleted? deleted... are you sure, there is no stalled udev process hanging around, which is/was using these device nodes? # find /sys -name dev | xargs grep 253 /sys/block/dm-0/dev:253:0 Ah, device mapper. I am not so sure this is a leftover from udev now. Could be lvm/devicemapper also.
yes, they are from udev. are there new devicemapper rules for 5.2 ?? # grep dm /etc/udev/rules.d/*
# grep dm /etc/udev/rules.d/* /etc/udev/rules.d/40-multipath.rules:KERNEL!="dm-[0-9]*", ACTION=="add", PROGRAM=="/bin/bash -c '/sbin/lsmod | /bin/grep ^dm_multipath'", RUN+="/sbin/multipath -v0 %M:%m" /etc/udev/rules.d/40-multipath.rules:KERNEL!="dm-[0-9]*", GOTO="end_mpath" /etc/udev/rules.d/40-multipath.rules:ACTION=="add", RUN+="/sbin/dmsetup ls --target multipath --exec '/sbin/kpartx -a -p p' -j %M -m %m" /etc/udev/rules.d/40-multipath.rules:PROGRAM=="/sbin/dmsetup ls --target multipath --exec /bin/basename -j %M -m %m", RESULT=="?*", NAME="%k", SYMLINK="mpath/%c", OPTIONS="last_rule" /etc/udev/rules.d/40-multipath.rules:PROGRAM!="/bin/bash -c '/sbin/dmsetup info -c --noheadings -j %M -m %m | /bin/grep -q .*:.*:.*:.*:.*:.*:.*:part[0-9]*-mpath-'", GOTO="end_mpath" /etc/udev/rules.d/40-multipath.rules:PROGRAM=="/sbin/dmsetup ls --target linear --exec /bin/basename -j %M -m %m", NAME="%k", RESULT=="?*", SYMLINK="mpath/%c", OPTIONS="last_rule" /etc/udev/rules.d/50-udev.rules:KERNEL=="admm*", MODE="0660" /etc/udev/rules.d/50-udev.rules:KERNEL=="dmfm*", MODE="0660" /etc/udev/rules.d/50-udev.rules:KERNEL=="dmmidi*", MODE="0660" /etc/udev/rules.d/90-dm.rules:KERNEL=="dm-[0-9]*", ACTION=="add", OPTIONS+="ignore_device" /etc/udev/rules.d/90-ib.rules:KERNEL=="rdma_cm", NAME="infiniband/%k", MODE="0666"
if you add in /etc/udev/rules.d/50-udev.rules after ACTION!="add", GOTO="persistent_end" the line: KERNEL=="dm-[0-9]*", GOTO="persistent_end" does it resolve the problem?
It sure does solve the problem! There are no /dev/.tmp-253-* device nodes after vgchange -a y (and of course there are no selinux denials caused by readahead trying to read them).
should be fixed with udev-095-14.14.el5
Devel ACK Read ya, Phil
Verified with udev-095-14.14.el5 / RHEL5.2-Server-20080207.nightly
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-0374.html