Bug 430667 - avc: denied { read } for comm="readahead" name=".tmp-253-0" dev=tmpfs
avc: denied { read } for comm="readahead" name=".tmp-253-0" dev=tmpfs
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: udev (Show other bugs)
All Linux
medium Severity medium
: rc
: ---
Assigned To: Harald Hoyer
Depends On:
  Show dependency treegraph
Reported: 2008-01-29 07:37 EST by Milan Zázrivec
Modified: 2008-05-21 11:59 EDT (History)
1 user (show)

See Also:
Fixed In Version: RHBA-2008-0374
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-05-21 11:59:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Milan Zázrivec 2008-01-29 07:37:46 EST
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:

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 09:41:47 EST
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 12:23:53 EST
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 03:22:18 EST
well, vol_id, scsi_id, etc. need temporary files
Comment 5 Daniel Walsh 2008-01-30 11:36:37 EST
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 11:57:31 EST
no, and no... not new and they are deleted afterwards IIRC
Comment 7 Harald Hoyer 2008-01-30 11:58:46 EST
and readahead should not take /tmp into account, anyway
Comment 8 Milan Zázrivec 2008-01-30 12:03:01 EST
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 03:52:52 EST
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 Product and Program Management 2008-02-01 03:57:26 EST
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
Comment 11 Harald Hoyer 2008-02-01 07:09:50 EST
> 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?


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

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 07:16:49 EST
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 07:23:19 EST
# 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",
/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",
/etc/udev/rules.d/90-ib.rules:KERNEL=="rdma_cm", NAME="infiniband/%k", MODE="0666"
Comment 14 Harald Hoyer 2008-02-01 07:34:40 EST
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 07:51:00 EST
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 06:57:51 EST
should be fixed with udev-095-14.14.el5
Comment 17 Phil Knirsch 2008-02-02 19:06:56 EST
Devel ACK

Read ya, Phil
Comment 20 Milan Zázrivec 2008-02-07 06:13:17 EST
Verified with udev-095-14.14.el5 / RHEL5.2-Server-20080207.nightly
Comment 22 errata-xmlrpc 2008-05-21 11:59:34 EDT
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.


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