Re: Moving Ubuntu to upstream udev rules

[Scott James Remnant <scott@canonical.com>]

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

On Fri, 2008-12-19 at 17:03 +0100, Kay Sievers wrote:

> > scd/sr
> > 
> >   while the kernel still calls them sr, that prefix is deprecated.  You
> >   symlink the new name to the old one, we do it the other way around to
> >   make it clearer:
> > 
> >     SUBSYSTEM=="block", KERNEL=="sr[0-9]*", NAME="scd%n", SYMLINK+="sr%
> 
> We do not want to change kernel names unless absolutely needed,
> especially for block devices we don't want to do that.
> 
> Where does the "deprecated prefix" information comes from? We should
> check with the kernel SCSI maintainers, and then do this, if it's the
> right thing.
> 
We set this up as devices.txt says to, with the name as the
non-deprecated one.

> > 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.

> >   additionally, we place these in the "audio" group
> > 
> >     SUBSYSTEM=="rtc", GROUP="audio"
> 
> Hmm, that sounds like a really weird workaround of some audio problem.
> Is this really what we want. :)
> 
Actually, drop this one.  We don't want it anymore.

> > 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.

> >   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?

> > 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

> >     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

> >   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.

> >   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.

> > 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.

Scott
-- 
Scott James Remnant
scott@canonical.com

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]