On Mon, Dec 22, 2008 at 10:39, Scott James Remnant <scott@xxxxxxxxxxxxx> wrote: > On Fri, 2008-12-19 at 17:03 +0100, Kay Sievers wrote: >> > rtc >> > >> > our rtc rules are more careful about only symlinking the CMOS >> > to /dev/rtc: >> > >> > SUBSYSTEM=="rtc", DRIVERS=="rtc_cmos", SYMLINK+="rtc" >> >> Sounds fine if we do not want that for other drivers? It's only >> compatibility for old x86 behavior? >> > As far as I know, I talked with the upstream about it for a while before > adding the rule. Fine. I've added this already. >> > raw1394 >> > >> > This should be in the "disk" group, not the "video" group; it can be >> > used to execute code as root >> >> It may not belong into be in the "video" group, but you definitely also >> don't want to put anybody in the "disk" group to access it, it's almost >> the same as being root. We can leave it as root, if we need to change it >> for security measures. >> >> You can not execute code on the host, only on a device, which may be >> another box connected over firewire, right? >> > Loopback cable? This is something our security guy and kernel > maintainer (who is the upstream maintainer of the old firewire system) > felt strongly about -- obviously new firewire stack is much better > anyway. It's hard to find a box with a single firewire controller. :) Removed the group, it's root now. >> > you also don't rename some devices, and thus disagree >> > >> > KERNEL=="controlC[0-9]*", NAME="snd/%k" >> > KERNEL=="hwC[D0-9]*", NAME="snd/%k" >> > KERNEL=="midiC[D0-9]*", NAME="snd/%k" >> > KERNEL=="pcmC[D0-9cp]*", NAME="snd/%k" >> > KERNEL=="seq", NAME="snd/%k" >> > KERNEL=="timer", NAME="snd/%k" >> >> That's in packages/40-alsa.rules. We do not carry it in the default udev >> rules, but in the alsa package. >> > These aren't installed by default, right? If we're all using the same > rules, is there any reason not to? There are many other alsa rules for loading "soundfonts" and such, so we moved these ones to the alsa package too. >> > symlinks >> > >> > you have lots of extra symlinks, any particular reason? are you paid >> > by the symlink? :p >> > >> > X0R -> null ??!! WTF >> >> It's in devices.txt. :) Harald wanted it. :) >> > I'm ok with it if it's in devices.txt :p It's gone. Forget devices.txt, nobody maintains this thing anymore. >> > vbi -> vbi0 >> > radio -> radio0 >> > video -> video0 >> >> That is needed for some old tools. People have complained. >> > We've not had these, and nobody complains too loudly ;) I want to avoid > adding legacy symlinks to our config if I can help it, because people > then will complain if they go away again later :p Ok, we will see. They are all gone now. I agree, in most cases the tools should be changed, or people should use their own rules. >> > no /dev/pilot? :) >> >> No, that doesn't work reliably, you never know which port is the right >> one. It can not be done with udev today, only with a specific >> vendor/device list match. >> > See vbi, radio, video, etc. above :p you can't have them and complain > about this ;) I'd rather have none of them, and leave legacy/deprecated > symlinks to distro-specific rules. Yeah, but vbi, radio, video was not wrong, did never point to a device which actually is not a vbi, radio, video device. For half of the devices, /dev/pilot pointed to a device which did not give access to the pilot. :) >> > tty 620 instead of 600? your ttys are writable? >> >> No idea. Just change it? >> > wall/write related. I'm happy to change to your default. Fine. >> > groups >> > >> > no cdrom group? >> > no scanner group? >> > no tape group? >> > no dialout group? - this may be Debianish, but we rely on it >> >> We do not want to put users in any such groups, but use dynamically >> assigned and managed ACLs for it. We use groups only for easy setups of >> system daemons like "video", for a streaming server and such. These >> groups do not make much sense for Fedora or SUSE, and you may want >> to put them in your own rules, in cases we don't find a common solution. >> > Agree, we can handle these in our own rules. Cool. Thanks, Kay -- 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
