udev-140 Bug: udevadm test changing mode of /dev to 660, so making /dev unusuable for users

udev-140 Bug: udevadm test changing mode of /dev to 660, so making /dev unusuable for users

[Matthias Schwarzott]

Hi there!

This time I have a very strange error. I tried what happens when using
# udevadm test /sys/class/mem/null

and strange, a bit later some user processes had problems accessing /dev/null.
A quick check showed, that the permissions of /dev were destroyed.

# ls -ld /dev /dev/null
drw-rw---- 16 root root 4280 18. Mär 11:14 /dev
crw-rw-rw-  1 root root 1, 3 17. Mär 08:05 /dev/null

Changing it back to 775 and retrying showed, that it must be udevadm test that 
destroys it.

# ls -ld /dev /dev/null
drwxrwxr-x 16 root root 4280 18. Mär 11:05 /dev
crw-rw-rw-  1 root root 1, 3 17. Mär 08:05 /dev/null

# udevadm test /sys/class/mem/null/
run_command: calling: test
udevadm_test: version 140
This program is for debugging only, it does not run any program,
specified by a RUN key. It may show incorrect results, because
some values may be different, or not available at a simulation run.

parse_file: reading '/dev/.udev/rules.d/10-root-link.rules' as rules file
parse_file: reading '/etc/udev/rules.d/15-em8300.rules' as rules file
parse_file: reading '/lib/udev/rules.d/30-kernel-compat.rules' as rules file
parse_file: reading '/lib/udev/rules.d/40-alsa.rules' as rules file
parse_file: reading '/lib/udev/rules.d/40-gentoo.rules' as rules file
parse_file: reading '/lib/udev/rules.d/40-isdn.rules' as rules file
parse_file: reading '/etc/udev/rules.d/40-lomoco.rules' as rules file
parse_file: reading '/etc/udev/rules.d/48-qemu.rules' as rules file
parse_file: reading '/lib/udev/rules.d/50-firmware.rules' as rules file
parse_file: reading '/lib/udev/rules.d/50-udev-default.rules' as rules file
parse_file: reading '/etc/udev/rules.d/55-usbirboy.rules' as rules file
parse_file: reading '/lib/udev/rules.d/60-cdrom_id.rules' as rules file
parse_file: reading '/etc/udev/rules.d/60-pcmcia.rules' as rules file
parse_file: reading '/lib/udev/rules.d/60-persistent-input.rules' as rules 
file
parse_file: reading '/lib/udev/rules.d/60-persistent-serial.rules' as rules 
file
parse_file: reading '/lib/udev/rules.d/60-persistent-storage-tape.rules' as 
rules file
parse_file: reading '/lib/udev/rules.d/60-persistent-storage.rules' as rules 
file
parse_file: reading '/lib/udev/rules.d/60-persistent-v4l.rules' as rules file
parse_file: reading '/etc/udev/rules.d/60-virtualbox.rules' as rules file
parse_file: reading '/lib/udev/rules.d/61-persistent-storage-edd.rules' as 
rules file
parse_file: reading '/etc/udev/rules.d/64-device-mapper.rules' as rules file
parse_file: reading '/etc/udev/rules.d/64-md-raid.rules' as rules file
parse_file: reading '/etc/udev/rules.d/70-bluetooth-pcmcia.rules' as rules 
file
parse_file: reading '/etc/udev/rules.d/70-bluetooth.rules' as rules file
parse_file: reading '/etc/udev/rules.d/70-libgphoto2.rules' as rules file
parse_file: reading '/etc/udev/rules.d/70-libsane.rules' as rules file
parse_file: reading '/etc/udev/rules.d/70-persistent-cd.rules' as rules file
parse_file: reading '/etc/udev/rules.d/70-persistent-net.rules' as rules file
parse_file: reading '/lib/udev/rules.d/75-cd-aliases-generator.rules' as rules 
file
parse_file: reading '/lib/udev/rules.d/75-persistent-net-generator.rules' as 
rules file
parse_file: reading '/lib/udev/rules.d/79-fstab_import.rules' as rules file
parse_file: reading '/lib/udev/rules.d/80-drivers.rules' as rules file
parse_file: reading '/etc/udev/rules.d/90-hal.rules' as rules file
parse_file: reading '/lib/udev/rules.d/90-network.rules' as rules file
parse_file: reading '/etc/udev/rules.d/90-zzam.rules' as rules file
parse_file: reading '/lib/udev/rules.d/95-udev-late.rules' as rules file
parse_file: reading '/etc/udev/rules.d/99-fuse.rules' as rules file
parse_file: reading '/etc/udev/rules.d/99-iscan.rules' as rules file
udev_rules_new: rules use 94332 bytes tokens (7861 * 12 bytes), 14704 bytes 
buffer
udev_rules_new: temporary index used 31800 bytes (1590 * 20 bytes)
udev_device_new_from_syspath: device 0x8d120c0 has devpath '/class/mem/null/'
udev_device_new_from_syspath: device 0x8d122c8 has devpath '/class/mem/null/'
udev_device_read_db: device 0x8d122c8 filled with db symlink data '/dev/'
udev_rules_apply_to_event: 
LINK 'char/1:3' /lib/udev/rules.d/50-udev-default.rules:5
udev_device_new_from_syspath: device 0x8d125e0 has 
devpath '/devices/virtual/mem/null'
udev_rules_apply_to_event: 
RUN 'socket:/org/freedesktop/hal/udev_event' /etc/udev/rules.d/90-hal.rules:2
udev_rules_apply_to_event: 
RUN 'socket:@/org/kernel/udev/monitor' /lib/udev/rules.d/95-udev-late.rules:7
udev_event_execute_rules: no node name set, will use kernel name ''
udev_device_update_db: create db link ( char/1:3)
udev_node_add: creating device node '/dev/', devnum=1:3, mode\x0660, uid=0, 
gid=0
udev_node_mknod: atomically replace existing file '/dev/'
udev_node_mknod: rename(/dev/.udev-tmp, /dev/) failed: Invalid cross-device 
link
udev_node_mknod: chmod(/dev/, 020660)
udev_node_mknod: chown(/dev/, 0, 0)
update_link: found 2 devices with name '/dev/char/1:3'
udev_device_new_from_syspath: device 0x8d12878 has 
devpath '/devices/virtual/mem/null'
udev_device_read_db: device 0x8d12878 filled with db symlink data '/dev/null'
update_link: '/dev/char/1:3' with target '/dev/' has the highest priority 0, 
create it
node_symlink: atomically replace '/dev/char/1:3'
udevadm_test: run: 'socket:/org/freedesktop/hal/udev_event'
udevadm_test: run: 'socket:@/org/kernel/udev/monitor'

# ls -ld /dev /dev/null
drw-rw---- 16 root root 4280 18. Mär 11:14 /dev
crw-rw-rw-  1 root root 1, 3 17. Mär 08:05 /dev/null

So it does something strange, maybe some rules are corrupt or misinterpreted.

Regards
Matthias

Re: udev-140 Bug: udevadm test changing mode of /dev to 660, so

[Kay Sievers]

On Wed, Mar 18, 2009 at 11:21, Matthias Schwarzott <zzam@gentoo.org> wrote:
> This time I have a very strange error. I tried what happens when using
> # udevadm test /sys/class/mem/null
>
> and strange, a bit later some user processes had problems accessing /dev/null.
> A quick check showed, that the permissions of /dev were destroyed.
>
> # ls -ld /dev /dev/null
> drw-rw---- 16 root root 4280 18. Mär 11:14 /dev
> crw-rw-rw-  1 root root 1, 3 17. Mär 08:05 /dev/null
>
> Changing it back to 775 and retrying showed, that it must be udevadm test that
> destroys it.
>
> # ls -ld /dev /dev/null
> drwxrwxr-x 16 root root 4280 18. Mär 11:05 /dev
> crw-rw-rw-  1 root root 1, 3 17. Mär 08:05 /dev/null
>
> # udevadm test /sys/class/mem/null/

> udev_device_read_db: device 0x8d122c8 filled with db symlink data '/dev/'
...
> udev_node_add: creating device node '/dev/', devnum=1:3, mode\x0660, uid=0,  gid=0
> udev_node_mknod: atomically replace existing file '/dev/'

Hmm, strange. What happended to your device node name?

I get:
  udev_device_read_db: device 0x62d3d0 filled with db symlink data '/dev/null'
  ...
  udev_node_add: creating device node '/dev/null', devnum=1:3,
mode\x0666, uid=0, gid=0

Kay

Re: udev-140 Bug: udevadm test changing mode of /dev to 660, so making /dev unusuable for users

[Matthias Schwarzott]

On Mittwoch, 18. März 2009, Matthias Schwarzott wrote:
> Hi there!
>
> This time I have a very strange error. I tried what happens when using
> # udevadm test /sys/class/mem/null
>
> and strange, a bit later some user processes had problems accessing
> /dev/null. A quick check showed, that the permissions of /dev were
> destroyed.
>
> # ls -ld /dev /dev/null
> drw-rw---- 16 root root 4280 18. Mär 11:14 /dev
> crw-rw-rw-  1 root root 1, 3 17. Mär 08:05 /dev/null
>

I found out how the error occurs:
It is a difference between
A. udevadm test /sys/class/mem/null/
and
B. udevadm test /sys/class/mem/null

Case A was the case that showed the error behaviour. It seems udevadm is 
confused by the trailing slash. This behaviour seems to be there since ages. 
So there are 2 things that might be done.
1. Make the code more robust, fix error path of failing rename operation to 
not call chmod after it. (I did not fully understand this code).
2. Catch the above case and either strip of the trailing slash or add a better 
solution that normalizes the path and extracts "KERNEL".

Regards
Matthias

Re: udev-140 Bug: udevadm test changing mode of /dev to 660, so

[Kay Sievers]

On Wed, Mar 18, 2009 at 16:00, Matthias Schwarzott <zzam@gentoo.org> wrote:
> On Mittwoch, 18. März 2009, Matthias Schwarzott wrote:
>> This time I have a very strange error. I tried what happens when using
>> # udevadm test /sys/class/mem/null
>>
>> and strange, a bit later some user processes had problems accessing
>> /dev/null. A quick check showed, that the permissions of /dev were
>> destroyed.
>>
>> # ls -ld /dev /dev/null
>> drw-rw---- 16 root root 4280 18. Mär 11:14 /dev
>> crw-rw-rw-  1 root root 1, 3 17. Mär 08:05 /dev/null
>>
>
> I found out how the error occurs:
> It is a difference between
> A. udevadm test /sys/class/mem/null/
> and
> B. udevadm test /sys/class/mem/null
>
> Case A was the case that showed the error behaviour. It seems udevadm is
> confused by the trailing slash. This behaviour seems to be there since ages.

Should be fixed now.

Thanks,
Kay

Re: udev-140 Bug: udevadm test changing mode of /dev to 660, so making /dev unusuable for users

[Matthias Schwarzott]

[-- Attachment #1: Type: text/plain, Size: 1465 bytes --]

On Mittwoch, 18. März 2009, Kay Sievers wrote:
> On Wed, Mar 18, 2009 at 16:00, Matthias Schwarzott <zzam@gentoo.org> wrote:
> > On Mittwoch, 18. März 2009, Matthias Schwarzott wrote:
> >> This time I have a very strange error. I tried what happens when using
> >> # udevadm test /sys/class/mem/null
> >>
> >> and strange, a bit later some user processes had problems accessing
> >> /dev/null. A quick check showed, that the permissions of /dev were
> >> destroyed.
> >>
> >> # ls -ld /dev /dev/null
> >> drw-rw---- 16 root root 4280 18. Mär 11:14 /dev
> >> crw-rw-rw-  1 root root 1, 3 17. Mär 08:05 /dev/null
> >
> > I found out how the error occurs:
> > It is a difference between
> > A. udevadm test /sys/class/mem/null/
> > and
> > B. udevadm test /sys/class/mem/null
> >
> > Case A was the case that showed the error behaviour. It seems udevadm is
> > confused by the trailing slash. This behaviour seems to be there since
> > ages.
>
> Should be fixed now.
>
Works fine, thanks for the quick fix.

Still I can easily find more ways to fool udevadm test going wrong.

# udevadm test /sys/class/mem/null/./
Fail in the same way.
udev_event_execute_rules: no node name set, will use kernel name '.'

Maybe it helps to make the node creation abort in case of rename failure, 
patch attached. But I have no real understanding of all codepathes there, so 
maybe this solution is not possible/correct.

Regards
Matthias

[-- Attachment #2: udev-140-abort-node-creation-on-rename-failure.patch --]
[-- Type: text/x-diff, Size: 370 bytes --]

diff --git a/udev/udev-node.c b/udev/udev-node.c
index 74ec00b..92a680d 100644
--- a/udev/udev-node.c
+++ b/udev/udev-node.c
@@ -106,6 +106,7 @@ int udev_node_mknod(struct udev_device *dev, const char *file, dev_t devnum, mod
 			if (err != 0) {
 				err(udev, "rename(%s, %s) failed: %m\n", file_tmp, file);
 				unlink(file_tmp);
+				goto exit;
 			}
 		}
 	} else {