On Mon, 19.07.10 13:52, Daniel J Walsh (dwalsh(a)redhat.com) wrote:
I am noticing the following in F14
type=1400 audit(1279559591.480:31): avc: denied { read } for pid=526
comm="udevd" name="/" dev=autofs ino=9519
scontext=system_u:system_r:udev_t:s0-s0:c0.c1023
tcontext=system_u:object_r:autofs_t:s0 tclass=dir
type=1400 audit(1279559595.968:35): avc: denied { read } for pid=880
comm="blkid" name="/" dev=autofs ino=9522
scontext=system_u:system_r:fsadm_t:s0-s0:c0.c1023
tcontext=system_u:object_r:autofs_t:s0 tclass=dir
type=AVC msg=audit(1279559629.289:59): avc: denied { read } for
pid=2013 comm="vgchange" name="/" dev=autofs ino=9522
scontext=system_u:system_r:lvm_t:s0-s0:c0.c1023
tcontext=system_u:object_r:autofs_t:s0 tclass=dir
type=PATH msg=audit(1279559629.289:59): item=0 name="/dev/mqueue"
inode=9522 dev=00:21 mode=040755 ouid=0 ogid=0 rdev=00:00
obj=system_u:object_r:autofs_t:s0
These AVC messages indicate lots of daemons that are trying to list the
contents of a directory labeled autofs_t. udevd, blkid, vgchange.
Do you have any idea what is going on here? Am I going to have to allow
all daemons to list the contents of autofs_t?
Those are the automount directories we install for /dev/mqueue,
/dev/hugepages, /proc/sys/fs/binfmt_misc, and the other API mounts. On
first access those automount points will be replaced by the actual file
systems. That allows us to make the mounts available right-away without
actually having to load the modules implementing them.
I am not entirely sure though why those processes actually access those
dirs in this case. Maybe they are iterating through the files in /dev?
Smells a bit broken to me.
Will I have to allow all daemons to list the contents of hugetlbfs_t?
Well, I see no reason why the LVM tools, or udev might need to access
the mqueue or hugetlbfs file system. They should not need access to it.
Or could these be leaks?
No, unlikely.
Lennart
--
Lennart Poettering - Red Hat, Inc.