On Mittwoch, 26. August 2009, Florian Zumbiehl wrote: > > Anyhow, the current code does potentially allow more access than one > would expect when interpreting udev's configuration using the > well-known semantics of unix permissions, which is kindof worse > than "just not working". The only case I can imagine where the race you try to describe gives more permission than meant by the rule writer is this scenario: 1. ruleset contains: KERNEL=="mydev", MODE="640", GROUP="readers" 2. after boot: # ls -l /dev/mydev brw-r----- 1 root writers ?, ? 25. Aug 16:09 /dev/mydev 3. Change the ruleset to contain (udev will reload it notified by inotify): KERNEL=="mydev", MODE="660", GROUP="writers" 4. run udevadm trigger 5. udev will process the new rule and 6. first chmod /dev/mydev # ls -l /dev/mydev brw-rw---- 1 root readers ?, ? 25. Aug 16:09 /dev/mydev 7. and then chown /dev/mydev so it gets its final permissions # ls -l /dev/mydev brw-rw---- 1 root writers ?, ? 25. Aug 16:09 /dev/mydev So there is this small time window between 6 and 7 where group readers has more permissions it should. BUT: This can only happen if admin changes the rules, or does manually adjust permissions of some devices and then triggers udev. If you show that this can really happen one could do something like this: 1. first chmod to safe umask (either logical and of old and new umask, or 0000) 2. then chown 3. then chmod to new umask Regards Matthias -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
