Bug 430667 - avc: denied { read } for comm="readahead" name=".tmp-253-0" dev=tmpfs
Summary: avc: denied { read } for comm="readahead" name=".tmp-253-0" dev=tmpfs
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: udev
Version: 5.2
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Harald Hoyer
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-01-29 12:37 UTC by Milan Zázrivec
Modified: 2008-05-21 15:59 UTC (History)
1 user (show)

Fixed In Version: RHBA-2008-0374
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-05-21 15:59:34 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2008:0374 0 normal SHIPPED_LIVE udev bug fix update 2008-05-20 13:23:41 UTC

Description Milan Zázrivec 2008-01-29 12:37:46 UTC
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

Comment 2 Daniel Walsh 2008-01-29 14:41:47 UTC
There should not be .tmp-353-0 blk_files on /dev?

This is either a udev/anaconda/fstools problem.

Comment 3 Milan Zázrivec 2008-01-29 17:23:53 UTC
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

Comment 4 Harald Hoyer 2008-01-30 08:22:18 UTC
well, vol_id, scsi_id, etc. need temporary files

Comment 5 Daniel Walsh 2008-01-30 16:36:37 UTC
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.

Comment 6 Harald Hoyer 2008-01-30 16:57:31 UTC
no, and no... not new and they are deleted afterwards IIRC

Comment 7 Harald Hoyer 2008-01-30 16:58:46 UTC
and readahead should not take /tmp into account, anyway

Comment 8 Milan Zázrivec 2008-01-30 17:03:01 UTC
The thing is those devices are created in /dev directory with
system_u:object_r:device_t label and certainly are not deleted afterwards.

Comment 9 Milan Zázrivec 2008-02-01 08:52:52 UTC
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.

Comment 10 RHEL Program Management 2008-02-01 08:57:26 UTC
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.

Comment 11 Harald Hoyer 2008-02-01 12:09:50 UTC
> 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.

Comment 12 Harald Hoyer 2008-02-01 12:16:49 UTC
yes, they are from udev. are there new devicemapper rules for 5.2 ??

# grep dm /etc/udev/rules.d/*

Comment 13 Milan Zázrivec 2008-02-01 12:23:19 UTC
# 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"

Comment 14 Harald Hoyer 2008-02-01 12:34:40 UTC
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?




Comment 15 Milan Zázrivec 2008-02-01 12:51:00 UTC
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).

Comment 16 Harald Hoyer 2008-02-02 11:57:51 UTC
should be fixed with udev-095-14.14.el5

Comment 17 Phil Knirsch 2008-02-03 00:06:56 UTC
Devel ACK

Read ya, Phil

Comment 20 Milan Zázrivec 2008-02-07 11:13:17 UTC
Verified with udev-095-14.14.el5 / RHEL5.2-Server-20080207.nightly

Comment 22 errata-xmlrpc 2008-05-21 15:59:34 UTC
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



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