Bug 627975

Are these being created by systemd?  dracut?  Why aren't they being labeled correctly by udev?

(In reply to comment #1)
> Are these being created by systemd?  dracut?  Why aren't they being labeled
> correctly by udev?

hmm... nothing changed regarding the selinux code.

So, what I can imaging, is that:

- they are present in devtmpfs and not yet managed by udev
- the modules are not yet loaded

what is the output of:

# for i in /dev/{watchdog,hugepages,hugepages/libvirt,hugepages/libvirt/qemu,microcode}; do udevadm info --query=all --name=$i;done

(In reply to comment #2)
> (In reply to comment #1)
> > Are these being created by systemd?  dracut?  Why aren't they being labeled
> > correctly by udev?
> 
> hmm... nothing changed regarding the selinux code.
> 
> So, what I can imaging, is that:
> 
> - they are present in devtmpfs and not yet managed by udev
> - the modules are not yet loaded
> 
> what is the output of:
> 
> # for i in
> /dev/{watchdog,hugepages,hugepages/libvirt,hugepages/libvirt/qemu,microcode};
> do udevadm info --query=all --name=$i;done

On my system:

[root@tlondon ~]# for i in /dev/{watchdog,hugepages,hugepages/libvirt,hugepages/libvirt/qemu,microcode}; do echo $i; ls -lZ $i; udevadm info --query=all --name=$i;done
/dev/watchdog
crw-------. root root system_u:object_r:device_t:s0    /dev/watchdog
P: /devices/virtual/misc/watchdog
N: watchdog
S: char/10:130
E: UDEV_LOG=3
E: DEVPATH=/devices/virtual/misc/watchdog
E: SUBSYSTEM=misc
E: DEVNAME=/dev/watchdog
E: MAJOR=10
E: MINOR=130
E: DEVLINKS=/dev/char/10:130

/dev/hugepages
drwxr-xr-x. root root system_u:object_r:hugetlbfs_t:s0 libvirt
device node has wrong file type
/dev/hugepages/libvirt
drwxr-xr-x. qemu qemu system_u:object_r:hugetlbfs_t:s0 qemu
device node has wrong file type
/dev/hugepages/libvirt/qemu
device node has wrong file type
/dev/microcode
ls: cannot access /dev/microcode: No such file or directory
device node not found
[root@tlondon ~]#

"device node has wrong file type" ? So they are not devices?

Hmm... "fleeting nodes"?

I also noticed this AVC in this morning's boot:

[root@tlondon ~]# dmesg | grep avctype=1400 audit(1283173495.780:4): avc:  denied  { mmap_zero } for  pid=475 comm="vbetool" scontext=system_u:system_r:vbetool_t:s0-s0:c0.c1023 tcontext=system_u:system_r:vbetool_t:s0-s0:c0.c1023 tclass=memprotect
type=1400 audit(1283173497.707:5): avc:  denied  { read } for  pid=748 comm="alsactl" name="controlC0" dev=devtmpfs ino=11551 scontext=system_u:system_r:alsa_t:s0-s0:c0.c1023 tcontext=system_u:object_r:device_t:s0 tclass=chr_file
[root@tlondon ~]# 

[Ignore the first one....]

Now:
[root@tlondon ~]# ls -li /dev/snd/controlC0
11551 crw-rw----+ 1 root audio 116, 9 Aug 30 06:04 /dev/snd/controlC0
[root@tlondon ~]# 

So this is the "right" node, but the AVC reports the "wrong" label, namely device_t.  But

[root@tlondon ~]# ls -lZ /dev/snd/controlC0
crw-rw----+ root audio system_u:object_r:sound_device_t:s0 /dev/snd/controlC0
[root@tlondon ~]# 

So this is being reported now as sound_device_t.

Got 2 more (similar?) with this morning's boot:

Aug 31 06:04:48 tlondon kernel: type=1403 audit(1283259864.919:3): policy loaded auid=4294967295 ses=4294967295
Aug 31 06:04:48 tlondon kernel: dracut:
Aug 31 06:04:48 tlondon kernel: type=1400 audit(1283259865.215:4): avc:  denied  { associate } for  pid=383 comm="restorecon" name="pts" dev=devtmpfs ino=6130 scontext=system_u:object_r:devpts_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=filesystem
Aug 31 06:04:48 tlondon kernel: type=1400 audit(1283259865.218:5): avc:  denied  { associate } for  pid=383 comm="restorecon" name="shm" dev=devtmpfs ino=6127 scontext=system_u:object_r:tmpfs_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=filesystem
Aug 31 06:04:48 tlondon kernel: dracut: Switching root

Can't seem to find either of these files... 'find / -inum {6130,6127} -print' returns nothing appropriate:

[root@tlondon tmp]# find / -inum 6130 -print
find: `/home/tbl/.gvfs': Permission denied
/sys/kernel/slab/xfrm_dst_cache/order
[root@tlondon tmp]# 

and

[root@tlondon tmp]# find / -inum 6127 -print
find: `/home/tbl/.gvfs': Permission denied
/sys/kernel/slab/xfrm_dst_cache/slab_size
[root@tlondon tmp]# 

Every few boots I seem to get some similar AVCs.

/dev/nvidia0 and /dev/nvidiactl have incorrect SElinx labels, too.

Is this issue nvidia closed driver bug? or udev bug?

udev-167-4.fc15.x86_64, nvidia closed driver 270.41.0X.

See Also : bug 694918

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

This appears to be a Fedora 15 bug. If you can reproduce this on a recent, supported Fedora version, please reopen.