Bug 145041 - start_udev and /etc/udev/devices
start_udev and /etc/udev/devices
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: udev (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Harald Hoyer
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-01-13 16:46 EST by Ivan Gyurdiev
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-02-19 17:41:17 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Ivan Gyurdiev 2005-01-13 16:46:46 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041228 Firefox/1.0 Fedora/1.0-8

Description of problem:
audit(1105622933.678:0): avc:  denied  { getattr } for  pid=678
exe=/bin/cp path=/etc/udev/devices/nvidia0 dev=dm-0 ino=665505
scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t
tclass=chr_file

audit(1105648170.174:0): avc:  denied  { unlink } for  pid=2291
exe=/bin/rm name=nvidia0 dev=tmpfs ino=1991
scontext=system_u:system_r:sysadm_t
tcontext=system_u:object_r:device_t tclass=chr_file

audit(1105648170.188:0): avc:  denied  { create } for  pid=2292
exe=/bin/mknod name=nvidia0 scontext=system_u:system_r:sysadm_t
tcontext=system_u:object_r:device_t tclass=chr_file

audit(1105648170.190:0): avc:  denied  { setattr } for  pid=2293
exe=/bin/chmod name=nvidia0 dev=tmpfs ino=6016
scontext=system_u:system_r:sysadm_t
tcontext=system_u:object_r:device_t tclass=chr_file


Version-Release number of selected component (if applicable):
selinux-policy-strict-1.21.1-1

How reproducible:
Didn't try

Steps to Reproduce:

    

Additional info:
Comment 1 Ivan Gyurdiev 2005-01-13 22:10:51 EST
Also: xscreensaver denials on nvidiactl

audit(1105658137.308:0): avc:  denied  { read write } for  pid=4944
exe=/usr/libexec/xscreensaver/hacks/rubik name=nvidiactl dev=tmpfs
ino=6040 scontext=user_u:user_r:user_t
tcontext=system_u:object_r:xserver_misc_device_t tclass=chr_file

audit(1105658137.308:0): avc:  denied  { ioctl } for  pid=4944
exe=/usr/libexec/xscreensaver/hacks/rubik path=/dev/nvidiactl
dev=tmpfs ino=6040 scontext=user_u:user_r:user_t
tcontext=system_u:object_r:xserver_misc_device_t tclass=chr_file

dev=tmpfs ino=6040 scontext=user_u:user_r:user_t
tcontext=system_u:object_r:xserver_misc_device_t tclass=chr_file
audit(1105669487.127:0): avc:  denied  { read write } for  pid=5953
exe=/usr/libexec/xscreensaver/hacks/cage name=nvidiactl dev=tmpfs
ino=6040 scontext=user_u:user_r:user_t 
tcontext=system_u:object_r:xserver_misc_device_t tclass=chr_file

audit(1105669487.127:0): avc:  denied  { ioctl } for  pid=5953
exe=/usr/libexec/xscreensaver/hacks/cage path=/dev/nvidiactl dev=tmpfs
ino=6040 scontext=user_u:user_r:user_t
tcontext=system_u:object_r:xserver_misc_device_t tclass=chr_file

Comment 2 Ivan Gyurdiev 2005-01-18 17:54:07 EST
Heh, I installed nvidia-glx and now I get 256 of the udev->etc_t
denials. udev denials confirmed in enforcing mode.


Comment 3 Ivan Gyurdiev 2005-01-19 05:36:40 EST
This fixes some of the problems for me:

--- start_udev.bak      2005-01-19 02:13:43.000000000 -0700
+++ start_udev  2005-01-19 03:25:04.000000000 -0700
@@ -55,7 +55,9 @@
                        echo net/tun ppp console null zero cpu/microcode;
                );
                [ -a /dev/MAKEDEV ] || ln -s $MAKEDEV /dev/MAKEDEV;
-               cp -a /etc/udev/devices/* /dev/ >/dev/null 2>&1 || :
+
+               cp -a /etc/udev/devices/* /$udev_root/ > /dev/null
2>&1 || :
+               restorecon /$udev_root/* > /dev/null 2>&1 || :
        fi
 }

--- udev.old    2005-01-19 02:26:26.000000000 -0700
+++ udev.fc     2005-01-19 02:26:14.000000000 -0700
@@ -6,6 +6,7 @@
 /usr/bin/udevinfo --   system_u:object_r:udev_exec_t
 /etc/dev\.d/.+ --      system_u:object_r:udev_helper_exec_t
 /etc/udev/scripts/.+   -- system_u:object_r:udev_helper_exec_t
+/etc/udev/devices/.*   system_u:object_r:device_t
 /etc/hotplug\.d/default/udev.* -- system_u:object_r:udev_helper_exec_t
 /dev/udev\.tbl --      system_u:object_r:udev_tbl_t
 /dev/\.udev\.tdb/.*    --      system_u:object_r:udev_tdb_t

I wanted to do restorecon on the devicies being copied only,
but restorecon is absurdly slow when cycling over 256 nvidia cards.
It's a lot faster when you invoke it once with args, but I don't
think the shell will tolerate that many arguments.

Consequences of restorecon on /dev:
/dev/shm is restored from tmpfs_t to device_t every time.

The xscreensaver problems are a different issue, and I will file a
different bug for that. 
Comment 4 Daniel Walsh 2005-01-19 09:14:59 EST
You can pipe a list to restorecon

cat /tmp/filelist | restorecon -v -f -
Comment 5 Ivan Gyurdiev 2005-01-20 00:29:23 EST
Is this the correct idea though? Restorecon 
when copying the device files?

Perhaps you should fix start_udev somehow.
I am having some trouble getting awk under control -
I never really liked scripting.

Comment 6 Ivan Gyurdiev 2005-01-22 03:45:20 EST
Details...? why NOTABUG? Without doing *something* about the context
of the files in /etc/udev/devices they end up having the wrong context when put in
/dev.

Now you could either restorecon /dev (as suggested),
or you could store the correct contexts in /etc/udev/devices,
and copy them, or something else....
Comment 7 Ivan Gyurdiev 2005-01-26 03:29:48 EST
I also wrote a patch that changed types.fc 
to label all files in /dev, /udev, and /etc/udev/devices
identically using a macro. Then you could copy 
with the preserve context flag. It works well, but I thought
it was the wrong thing to do at the time vs. a restorecon
solution.

If you're interested in that approach I can attach patch.
Comment 8 Harald Hoyer 2005-01-26 06:46:49 EST
hmm, I would like to implement the restorecon. Btw, I "cp -a" which
means "cp -dpR" which should preserve the context. So, if you setup
the right contexts in /etc/udev/devices, then all should be fine.
Comment 9 Ivan Gyurdiev 2005-01-31 18:06:56 EST
What's the status of this bug? It has a simple resolution, so 
why is it not closed yet?

All that's needed is an efficient call to restorecon on
all the files installed in /dev by start_udev (one invocation,
not one per device)

Additionally, the file contexts for udev need
to be patched to have the device_t type.

Comment 10 Ivan Gyurdiev 2005-02-08 17:00:31 EST
file context patch merged, only start_udev fix is left here.



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