.udev.tdb ?

Tom London selinux at comcast.net
Wed Jul 21 16:05:31 UTC 2004


OK, done.

Here are a few entries from the resulting trace
of calls to restorecon from a clean reboot
with 'enforcing=0'. The first call is the
last one in the trace prior to a number
of calls from udev:

params:/var/run/sm-client.pid
total 4
lrwx------  1 root root 64 Jul 21 07:28 0 -> /dev/pts/0
l-wx------  1 root root 64 Jul 21 07:28 1 -> /root/file
lrwx------  1 root root 64 Jul 21 07:28 2 -> /dev/pts/0
lr-x------  1 root root 64 Jul 21 07:28 3 -> /proc/2423/fd
params:/dev/lp0
total 6
lrwx------  1 root root 64 Jul 21 07:28 0 -> socket:[906]
l-wx------  1 root root 64 Jul 21 07:28 1 -> /root/file
l-wx------  1 root root 64 Jul 21 07:28 2 -> pipe:[914]
lrwx------  1 root root 64 Jul 21 07:28 3 -> socket:[915]
lrwx------  1 root root 64 Jul 21 07:28 4 -> /dev/.udev.tdb
lr-x------  1 root root 64 Jul 21 07:28 5 -> /proc/2446/fd
params:/dev/snd/timer
total 6
lrwx------  1 root root 64 Jul 21 07:28 0 -> socket:[906]
l-wx------  1 root root 64 Jul 21 07:28 1 -> /root/file
l-wx------  1 root root 64 Jul 21 07:28 2 -> pipe:[914]
lrwx------  1 root root 64 Jul 21 07:28 3 -> socket:[915]
lrwx------  1 root root 64 Jul 21 07:28 4 -> /dev/.udev.tdb
lr-x------  1 root root 64 Jul 21 07:28 5 -> /proc/2632/fd
...... (many more)

As you suspected, it looks like udev is
leaving fd 4 (/dev/.udev.tdb) open
across the exec (i.e., has not set
FD_CLOEXEC).

I've bugzilla-ed this here:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=128304

Thanks for helping track this down.
   tom

Russell Coker wrote:

>On Wed, 21 Jul 2004 02:35, Tom London <selinux at comcast.net> wrote:
>  
>
>>Yikes.... sorry, but this doesn't look right....
>>now produces hordes of 'restorecon' avcs....
>>
>>Jul 20 09:23:46 fedora kernel: audit(1090340592.421:0): avc:  denied  {
>>read write } for  pid=991 exe=/sbin/restorecon path=/dev/.udev.tdb
>>dev=hda2 ino=2698913 scontext=system_u:system_r:restorecon_t
>>tcontext=system_u:object_r:udev_tbl_t tclass=file
>>    
>>
>
>udev calls restorecon to set the correct type of a device node it has just 
>created.
>
>restorecon has no business in opening /dev/.udev.tdb and I really doubt that 
>it is doing so.  I expect that udev is opening /dev/.udev.tdb, not using 
>fcntl(fd, F_SETFD, FD_CLOEXEC) to set the fd to close on execute, and not 
>calling close(fd) before the exec.
>
>Please file a bugzilla report about this.  To assist in tracking it down 
>rename /sbin/restorecon to /sbin/restorecon.orig and put the following shell 
>script in place as /sbin/restorecon:
>#!/bin/sh
>echo -n params: >> /root/file
>for n in $*; do echo -n "$n "; done >> /root/file
>echo "" >> /root/file
>ls -l /proc/self/fd >> /root/file
>exec /sbin/restorecon.orig $*
>
>Run the machine in permissive mode while doing this and don't bother about the 
>AVC messages about not being permitted to write to /root/file.
>
>  
>
>>Jul 20 09:23:47 fedora kernel: audit(1090340600.740:0): avc:  denied  {
>>unlink } for  pid=1297 exe=/sbin/udev name=microcode dev=hda2
>>ino=2689375 scontext=system_u:system_r:udev_t
>>tcontext=system_u:object_r:device_t tclass=lnk_file
>>    
>>
>
>allow udev_t device_t:lnk_file create_file_perms;
>Add the above policy to allow this.
>
>  
>



More information about the selinux mailing list