Moving Ubuntu to upstream udev rules (Part 2)

Moving Ubuntu to upstream udev rules (Part 2)

[Scott James Remnant]

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

Have now resync'd with the changes confirmed in the last thread, which
leaves just a handful of other bits (some of which mentioned before,
some of which I found in the later audit).

(Any differences I don't mention here, I'm happy to drop in favour of
upstream without further discussion.)

rules/rules.d/50-udev-default.rules:

  - KERNEL=="raw1394*", GROUP="video"

  This will still be difficult for me to upload with ;)

  - SUBSYSTEM=="block", KERNEL=="sr[0-9]*", SYMLINK+="scd%n"
  + SUBSYSTEM=="block", KERNEL=="sr[0-9]*", NAME="scd%n", SYMLINK+="%k"

  I still think we have this round the right way! :-)

  - KERNEL=="pty[pqrstuvwxyzabcdef][0123456789abcdef]", GROUP="tty", \
  -         MODE="0660", OPTIONS+="last_rule"
  - KERNEL=="tty[pqrstuvwxyzabcdef][0123456789abcdef]", GROUP="tty", \
  -         MODE="0660", OPTIONS+="last_rule"
  - KERNEL=="ptmx",                 GROUP="tty", MODE="0666", \
  -         OPTIONS+="last_rule"
  - KERNEL=="tty",                  GROUP="tty", MODE="0666", \
  -         OPTIONS+="last_rule"
  - KERNEL=="tty[0-9]*",            GROUP="tty", MODE="0620", \
  -         OPTIONS+="last_rule"
  - KERNEL=="vcs|vcs[0-9]*|vcsa|vcsa[0-9]*", GROUP="tty", \
  -         OPTIONS+="last_rule"
  - KERNEL=="console",              MODE="0600", OPTIONS+="last_rule"
  + KERNEL=="pty[pqrstuvwxyzabcdef][0123456789abcdef]", GROUP="tty", \
  +         MODE="0660",
  + KERNEL=="tty[pqrstuvwxyzabcdef][0123456789abcdef]", GROUP="tty", \
  +         MODE="0660",
  + KERNEL=="ptmx",                 GROUP="tty", MODE="0666"
  + KERNEL=="tty",                  GROUP="tty", MODE="0666"
  + KERNEL=="tty[0-9]*",            GROUP="tty", MODE="0620",
  + KERNEL=="vcs|vcs[0-9]*|vcsa|vcsa[0-9]*", GROUP="tty",
  + KERNEL=="console",              MODE="0600"

  last_rule on these prevents us from setting the console font or keymap
  from udev rules, and prevents us from activating console-related
  things (getty, brltty, etc.) from Upstart

  you said it was only there because of the legacy ptys, which we've
  both disabled now?

  - KERNEL=="tun", NAME="net/%k", MODE="0666", OPTIONS+="ignore_remove"
  + KERNEL=="tun", NAME="net/%k"

  The mode seems rather permissive?  Do you really allow any user to
  make tunnels by default?  (Ours is 0600!)

  Isn't the ignore_remove already handled by the /lib/udev/devices
  check?  Our /dev/net/tun is in there.

  - KERNEL=="ppp",        MODE="0600", OPTIONS+="ignore_remove"
  + KERNEL=="ppp",        MODE="0600"

  ignore_remove already handled by /lib/udev/devices check?

  - KERNEL=="mem|kmem|port|nvram",  GROUP="kmem", MODE="0640"
  + KERNEL=="mem|kmem|port",  GROUP="kmem", MODE="0640"
  + KERNEL=="nvram",  GROUP="nvram", MODE="0640"

  We have the nvram group, no idea why, we just do ;)

  - SUBSYSTEM=="block", GROUP="disk"
  + SUBSYSTEM=="block", ATTRS{removable}!="1", GROUP="disk"
  + SUBSYSTEM=="block", ATTRS{removable}=="1", GROUP="floppy"

  We put removable block devices in the floppy group, you leave them in
  disk?  (But use the floppy group for real floppies?)

  - KERNEL=="sg[0-9]*", ATTRS{type}!="3|6", GROUP="disk", MODE="0640"
  + SUBSYSTEMS=="scsi", ATTRS{type}=="0", GROUP="disk", MODE="0640"
  + SUBSYSTEMS=="scsi", ATTRS{type}=="4|5", GROUP="cdrom", MODE="0640"

  - KERNEL=="pktcdvd[0-9]*",        NAME="pktcdvd/%k"
  + KERNEL=="pktcdvd[0-9]*",        NAME="pktcdvd/%k", GROUP="cdrom"

  # eep, needs cdrom_id run earlier (we ran it at 30-* before)
  + ENV{ID_CDROM}=="?*",                    GROUP="cdrom"

  We put CD-ROM drives and similar into the cdrom group, not disk.

  + SUBSYSTEMS=="scsi", ATTRS{type}=="1|8", GROUP="tape"

  - KERNEL=="ht[0-9]*|nht[0-9]*",   GROUP="disk"
  + KERNEL=="ht[0-9]*|nht[0-9]*",   GROUP="tape"

  - KERNEL=="pt[0-9]*|npt[0-9]*",   GROUP="disk"
  + KERNEL=="pt[0-9]*|npt[0-9]*",   GROUP="tape"

  - KERNEL=="qft[0-9]*|nqft[0-9]*|zqft[0-9]*|nzqft[0-9]*|rawqft[0-9]*|
    nrawqft[0-9]*", GROUP="disk"
  + KERNEL=="qft[0-9]*|nqft[0-9]*|zqft[0-9]*|nzqft[0-9]*|rawqft[0-9]*|
    nrawqft[0-9]*", GROUP="tape"

  We put tape drives and similar into the tape group, not disk.


rules/rules.d/80-drivers.rules:

  - SUBSYSTEM=="module", KERNEL=="parport_pc", \
  -         RUN+="/sbin/modprobe -b ppdev"

  We don't have this one?  What's this for?  Is a module missing a
  dependency?

rules/packages/40-alsa.rules:

    KERNEL=="mixer0",               SYMLINK+="mixer"
    KERNEL=="dsp0",                 SYMLINK+="dsp"
    KERNEL=="audio0",               SYMLINK+="audio"

  Which kernel module/ALSA version creates these?  Here I can only
  see /dev/mixer, /dev/dsp and /dev/audio as devices in their own
  right.  Does a later ALSA version enumerate them, or were these added
  just in case?

  + SUBSYSTEM=="sound",                     GROUP="audio"

  And we have an "audio" group for them.

rules/packages/40-isdn.rules:

  - SUBSYSTEM=="capi", KERNEL=="capi", NAME="capi20", \
  -         SYMLINK+="isdn/capi20", GROUP="uucp"
  + SUBSYSTEM=="capi", KERNEL=="capi", NAME="capi20", \
  +         GROUP="uucp"

  What uses the /dev/isdn/capi20 symlink?  We've never had that, and
  I've never had any bug reports.


We have a "dialout" group, which we seem to use everywhere you use
"uucp".  I think that we inherited this from Debian: Marco, do these
differences match your rules?

It may make sense for these to be a Debian/Ubuntu diff, or a configure
argument?

rules/rules.d/50-udev-default.rules:

  - KERNEL=="tty[A-Z]*|pppox*|ircomm*|noz*", GROUP="uucp"
  + KERNEL=="tty[A-Z]*|pppox*|ircomm*|noz*", GROUP="dialout"

  - KERNEL=="mwave",                NAME="modems/mwave", GROUP="uucp"
  + KERNEL=="mwave",                NAME="modems/mwave", GROUP="dialout"

  - KERNEL=="hvc*|hvsi*",           GROUP="uucp"
  + KERNEL=="hvc*|hvsi*",           GROUP="dialout"

  + SUBSYSTEM=="slamr",             GROUP="dialout"

  + SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", \
  +     ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", \
  +                                      MODE="0660", GROUP="dialout"

rules/packages/40-isdn.rules:

  - SUBSYSTEM=="capi", KERNEL=="capi", NAME="capi20", \
  -         SYMLINK+="isdn/capi20", GROUP="uucp"
  + SUBSYSTEM=="capi", KERNEL=="capi", NAME="capi20", \
  +         SYMLINK+="isdn/capi20", GROUP="dialout"

rules/packages/40-zaptel.rules:

  + SUBSYSTEM=="zaptel", GROUP="dialout"

  (or just the GROUP= tagged onto the other rules for consistency)


Scott
-- 
Scott James Remnant
scott@ubuntu.com

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

Re: Moving Ubuntu to upstream udev rules (Part 2)

[Kay Sievers]

On Mon, Dec 22, 2008 at 15:20, Scott James Remnant <scott@ubuntu.com> wrote:
> Have now resync'd with the changes confirmed in the last thread, which
> leaves just a handful of other bits (some of which mentioned before,
> some of which I found in the later audit).
>
> (Any differences I don't mention here, I'm happy to drop in favour of
> upstream without further discussion.)
>
> rules/rules.d/50-udev-default.rules:
>
>  - KERNEL="raw1394*", GROUP="video"

Hmm, I removed that already, and replied to your other mail:
  http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h¨cf7cf2c7b4c41c14508a808b09a5fa9256a024

>  This will still be difficult for me to upload with ;)
>
>  - SUBSYSTEM="block", KERNEL="sr[0-9]*", SYMLINK+="scd%n"
>  + SUBSYSTEM="block", KERNEL="sr[0-9]*", NAME="scd%n", SYMLINK+="%k"
>
>  I still think we have this round the right way! :-)

devices.txt is in no way "right" for everything, that section is from
the 2.4 days, and may not mean anything today. I'll wait for the SCSI
guys to tell. We should not switch names if there will never be a scd*
device in the kernel, because that would mean that sr* is the default,
and scd* is the legacy. I'll come back as soon as I got an answer.

>  - KERNEL="pty[pqrstuvwxyzabcdef][0123456789abcdef]", GROUP="tty", \
>  -         MODE="0660", OPTIONS+="last_rule"
>  - KERNEL="tty[pqrstuvwxyzabcdef][0123456789abcdef]", GROUP="tty", \
>  -         MODE="0660", OPTIONS+="last_rule"
>  - KERNEL="ptmx",                 GROUP="tty", MODE="0666", \
>  -         OPTIONS+="last_rule"
>  - KERNEL="tty",                  GROUP="tty", MODE="0666", \
>  -         OPTIONS+="last_rule"
>  - KERNEL="tty[0-9]*",            GROUP="tty", MODE="0620", \
>  -         OPTIONS+="last_rule"
>  - KERNEL="vcs|vcs[0-9]*|vcsa|vcsa[0-9]*", GROUP="tty", \
>  -         OPTIONS+="last_rule"
>  - KERNEL="console",              MODE="0600", OPTIONS+="last_rule"
>  + KERNEL="pty[pqrstuvwxyzabcdef][0123456789abcdef]", GROUP="tty", \
>  +         MODE="0660",
>  + KERNEL="tty[pqrstuvwxyzabcdef][0123456789abcdef]", GROUP="tty", \
>  +         MODE="0660",
>  + KERNEL="ptmx",                 GROUP="tty", MODE="0666"
>  + KERNEL="tty",                  GROUP="tty", MODE="0666"
>  + KERNEL="tty[0-9]*",            GROUP="tty", MODE="0620",
>  + KERNEL="vcs|vcs[0-9]*|vcsa|vcsa[0-9]*", GROUP="tty",
>  + KERNEL="console",              MODE="0600"
>
>  last_rule on these prevents us from setting the console font or keymap
>  from udev rules, and prevents us from activating console-related
>  things (getty, brltty, etc.) from Upstart

Removed "last_rule".

>  you said it was only there because of the legacy ptys, which we've
>  both disabled now?

We set them to 0, and they can be requested on the boot command line.
We have not heard anyone using it so far. Here is the option:
  http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/kernel-parameters.txt;hàf346d201edb70fae654c55f6be842c4465a5ff;hb=HEAD#l1808

>  - KERNEL="tun", NAME="net/%k", MODE="0666", OPTIONS+="ignore_remove"
>  + KERNEL="tun", NAME="net/%k"
>
>  The mode seems rather permissive?  Do you really allow any user to
>  make tunnels by default?  (Ours is 0600!)

Hmm, I don't know. I see Ubuntu users complaining on the net, who use
virtualization not running as root. But if it's unsafe we should
change that.

>  Isn't the ignore_remove already handled by the /lib/udev/devices
>  check?  Our /dev/net/tun is in there.

Yeah, because it sets NAME= earlier to place it in the subdirectory.
The current check only covers devices which have NAME= set.

>  - KERNEL="ppp",        MODE="0600", OPTIONS+="ignore_remove"
>  + KERNEL="ppp",        MODE="0600"
>
>  ignore_remove already handled by /lib/udev/devices check?

ppp is not set by NAME=. I've added this, which should do it:
   ACTION="remove", NAME="", \
     TEST="/lib/udev/devices/%k", OPTIONS+="ignore_remove"

>  - KERNEL="mem|kmem|port|nvram",  GROUP="kmem", MODE="0640"
>  + KERNEL="mem|kmem|port",  GROUP="kmem", MODE="0640"
>  + KERNEL="nvram",  GROUP="nvram", MODE="0640"
>
>  We have the nvram group, no idea why, we just do ;)

Hmm, if there is a good reason. Maybe just drop "nvram", and wait if
anybody complains?

>  - SUBSYSTEM="block", GROUP="disk"
>  + SUBSYSTEM="block", ATTRS{removable}!="1", GROUP="disk"
>  + SUBSYSTEM="block", ATTRS{removable}="1", GROUP="floppy"
>
>  We put removable block devices in the floppy group, you leave them in
>  disk?  (But use the floppy group for real floppies?)

Putting gigabyte-big USB hard disks in the "floppy" group? Also some
ATA/SCSI storage controller are marked as removable. I don't think we
want that in the defaults. :)

>  - KERNEL="sg[0-9]*", ATTRS{type}!="3|6", GROUP="disk", MODE="0640"
>  + SUBSYSTEMS="scsi", ATTRS{type}="0", GROUP="disk", MODE="0640"
>  + SUBSYSTEMS="scsi", ATTRS{type}="4|5", GROUP="cdrom", MODE="0640"

We do not use "cdrom", but we could. Harald?

>  - KERNEL="pktcdvd[0-9]*",        NAME="pktcdvd/%k"
>  + KERNEL="pktcdvd[0-9]*",        NAME="pktcdvd/%k", GROUP="cdrom"

Harald, you have "cdrom", and that's fine ot use?

>  # eep, needs cdrom_id run earlier (we ran it at 30-* before)
>  + ENV{ID_CDROM}="?*",                    GROUP="cdrom"
>
>  We put CD-ROM drives and similar into the cdrom group, not disk.
>
>  + SUBSYSTEMS="scsi", ATTRS{type}="1|8", GROUP="tape"
>
>  - KERNEL="ht[0-9]*|nht[0-9]*",   GROUP="disk"
>  + KERNEL="ht[0-9]*|nht[0-9]*",   GROUP="tape"
>
>  - KERNEL="pt[0-9]*|npt[0-9]*",   GROUP="disk"
>  + KERNEL="pt[0-9]*|npt[0-9]*",   GROUP="tape"
>
>  - KERNEL="qft[0-9]*|nqft[0-9]*|zqft[0-9]*|nzqft[0-9]*|rawqft[0-9]*|
>    nrawqft[0-9]*", GROUP="disk"
>  + KERNEL="qft[0-9]*|nqft[0-9]*|zqft[0-9]*|nzqft[0-9]*|rawqft[0-9]*|
>    nrawqft[0-9]*", GROUP="tape"
>
>  We put tape drives and similar into the tape group, not disk.

Hmm, we don't have a "tape" group at all. Harald you have?

> rules/rules.d/80-drivers.rules:
>
>  - SUBSYSTEM="module", KERNEL="parport_pc", \
>  -         RUN+="/sbin/modprobe -b ppdev"
>
>  We don't have this one?  What's this for?  Is a module missing a
>  dependency?

It's for legacy parallel port, yes. Nobody will fix the kernel. Not
sure why we needed it and you don't. You have that as a loadable
module?

> rules/packages/40-alsa.rules:
>
>    KERNEL="mixer0",               SYMLINK+="mixer"
>    KERNEL="dsp0",                 SYMLINK+="dsp"
>    KERNEL="audio0",               SYMLINK+="audio"
>
>  Which kernel module/ALSA version creates these?  Here I can only
>  see /dev/mixer, /dev/dsp and /dev/audio as devices in their own
>  right.  Does a later ALSA version enumerate them, or were these added
>  just in case?

Not sure. Removed it! /dev/audio should just be just removed from the kernel.

>  + SUBSYSTEM="sound",                     GROUP="audio"
>
>  And we have an "audio" group for them.

Added. Harald, could you please check, that you get an "audio" group
too. It's as useful as "video", even when we do not put any "normal"
users, but only daemons in it.

> rules/packages/40-isdn.rules:
>
>  - SUBSYSTEM="capi", KERNEL="capi", NAME="capi20", \
>  -         SYMLINK+="isdn/capi20", GROUP="uucp"
>  + SUBSYSTEM="capi", KERNEL="capi", NAME="capi20", \
>  +         GROUP="uucp"
>
>  What uses the /dev/isdn/capi20 symlink?  We've never had that, and
>  I've never had any bug reports.

The old ISDN drivers are pretty much dead. But I've seen bugs about
/dev/capi20, and it seems used:
  http://www.google.com/codesearch?hl=en&sa=N&q=/dev/capi20++lang:c&ct=rr&cs_r=lang:c

> We have a "dialout" group, which we seem to use everywhere you use
> "uucp".  I think that we inherited this from Debian: Marco, do these
> differences match your rules?
>
> It may make sense for these to be a Debian/Ubuntu diff, or a configure
> argument?
>
> rules/rules.d/50-udev-default.rules:
>
>  - KERNEL="tty[A-Z]*|pppox*|ircomm*|noz*", GROUP="uucp"
>  + KERNEL="tty[A-Z]*|pppox*|ircomm*|noz*", GROUP="dialout"
>
>  - KERNEL="mwave",                NAME="modems/mwave", GROUP="uucp"
>  + KERNEL="mwave",                NAME="modems/mwave", GROUP="dialout"
>
>  - KERNEL="hvc*|hvsi*",           GROUP="uucp"
>  + KERNEL="hvc*|hvsi*",           GROUP="dialout"
>
>  + SUBSYSTEM="slamr",             GROUP="dialout"
>
>  + SUBSYSTEM="usb", ENV{DEVTYPE}="usb_device", \
>  +     ATTRS{idVendor}="0403", ATTRS{idProduct}="6001", \
>  +                                      MODE="0660", GROUP="dialout"
>
> rules/packages/40-isdn.rules:
>
>  - SUBSYSTEM="capi", KERNEL="capi", NAME="capi20", \
>  -         SYMLINK+="isdn/capi20", GROUP="uucp"
>  + SUBSYSTEM="capi", KERNEL="capi", NAME="capi20", \
>  +         SYMLINK+="isdn/capi20", GROUP="dialout"
>
> rules/packages/40-zaptel.rules:
>
>  + SUBSYSTEM="zaptel", GROUP="dialout"
>
>  (or just the GROUP= tagged onto the other rules for consistency)

If we can not agree on a default, we can do an option, but we do
nobody a favor who works on an upstream project and who needs to find
the differences again. So, I'm all for finding a common solution, For
me it would not be a problem to use "dialout" if that is what we want.
Harald?

Thanks,
Kay

Re: Moving Ubuntu to upstream udev rules (Part 2)

[Bernhard Walle]

* Kay Sievers [2008-12-22 16:30]:
>
> It's for legacy parallel port, yes. Nobody will fix the kernel. 

What should be "fixed" in that area? ppdev is only needed
for /dev/parport<x> (mostly accessed by libieee1284), not for printing
via /dev/lp<x>. That's why it is not loaded by default if a parallel
port is detected -- because it's optional.


Regards,
Bernhard

Re: Moving Ubuntu to upstream udev rules (Part 2)

[Kay Sievers]

On Mon, Dec 22, 2008 at 16:42, Bernhard Walle <bernhard.walle@gmx.de> wrote:
> * Kay Sievers [2008-12-22 16:30]:
>>
>> It's for legacy parallel port, yes. Nobody will fix the kernel.
>
> What should be "fixed" in that area?

There have been several attempts in the past to integrate the parport
infrastructure properly with the driver model. You can have a tree of
devices hanging off a parallel port, but that is not properly exported
the kernel. The last attempt was done by Hannes a while back, but it
never got finished. Legacy parport it's just dead today, and it will
never happen, I guess.

Kay

Re: Moving Ubuntu to upstream udev rules (Part 2)

[Scott James Remnant]

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

On Mon, 2008-12-22 at 16:30 +0100, Kay Sievers wrote:

> On Mon, Dec 22, 2008 at 15:20, Scott James Remnant <scott@ubuntu.com> wrote:
> >  This will still be difficult for me to upload with ;)
> >
> >  - SUBSYSTEM=="block", KERNEL=="sr[0-9]*", SYMLINK+="scd%n"
> >  + SUBSYSTEM=="block", KERNEL=="sr[0-9]*", NAME="scd%n", SYMLINK+="%k"
> >
> >  I still think we have this round the right way! :-)
> 
> devices.txt is in no way "right" for everything, that section is from
> the 2.4 days, and may not mean anything today. I'll wait for the SCSI
> guys to tell. We should not switch names if there will never be a scd*
> device in the kernel, because that would mean that sr* is the default,
> and scd* is the legacy. I'll come back as soon as I got an answer.
> 
No problem, will wait for that :)

> >  you said it was only there because of the legacy ptys, which we've
> >  both disabled now?
> 
> We set them to 0, and they can be requested on the boot command line.
> We have not heard anyone using it so far. Here is the option:
>   http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/kernel-parameters.txt;h=e0f346d201edb70fae654c55f6be842c4465a5ff;hb=HEAD#l1808
> 
We found one, an abandoned "ttyd" project; but so not caring about that.

http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-jaunty.git;a=commitdiff;h=4e79291096b0d6adc9726607c8f6b7df736a877e

> >  - KERNEL=="tun", NAME="net/%k", MODE="0666", OPTIONS+="ignore_remove"
> >  + KERNEL=="tun", NAME="net/%k"
> >
> >  The mode seems rather permissive?  Do you really allow any user to
> >  make tunnels by default?  (Ours is 0600!)
> 
> Hmm, I don't know. I see Ubuntu users complaining on the net, who use
> virtualization not running as root. But if it's unsafe we should
> change that.
> 
It's an interesting question actually, since you can make an ssh tunnel
anyway.  Kernel docs say it's ok to be 0666 since you need CAP_NET_ADMIN
anyway - so 666 it is.

> >  Isn't the ignore_remove already handled by the /lib/udev/devices
> >  check?  Our /dev/net/tun is in there.
> 
> Yeah, because it sets NAME= earlier to place it in the subdirectory.
> The current check only covers devices which have NAME= set.
> 
Slightly confused.

The general ignore_remove rule looks like:

ACTION=="remove", NAME=="?*", TEST=="/lib/udev/devices/$name", \
        OPTIONS+="ignore_remove"

Does this mean that this rule does nothing if the name isn't changed?
Want to understand where we need the ignore_remove option on rules, or
what is caught by this one.

> >  - KERNEL=="mem|kmem|port|nvram",  GROUP="kmem", MODE="0640"
> >  + KERNEL=="mem|kmem|port",  GROUP="kmem", MODE="0640"
> >  + KERNEL=="nvram",  GROUP="nvram", MODE="0640"
> >
> >  We have the nvram group, no idea why, we just do ;)
> 
> Hmm, if there is a good reason. Maybe just drop "nvram", and wait if
> anybody complains?
> 
Yeah, I think I'll probably just do that -- the udev package is what
creates the nvram group in the first place, so I suspect this is just
something we picked up from Debian once and never threw away.

I'll drop this.

> >  - SUBSYSTEM=="block", GROUP="disk"
> >  + SUBSYSTEM=="block", ATTRS{removable}!="1", GROUP="disk"
> >  + SUBSYSTEM=="block", ATTRS{removable}=="1", GROUP="floppy"
> >
> >  We put removable block devices in the floppy group, you leave them in
> >  disk?  (But use the floppy group for real floppies?)
> 
> Putting gigabyte-big USB hard disks in the "floppy" group? Also some
> ATA/SCSI storage controller are marked as removable. I don't think we
> want that in the defaults. :)
> 
Fair point ;)  I'll drop this.

(cdrom/tape pending Harald's reply)

> > rules/rules.d/80-drivers.rules:
> >
> >  - SUBSYSTEM=="module", KERNEL=="parport_pc", \
> >  -         RUN+="/sbin/modprobe -b ppdev"
> >
> >  We don't have this one?  What's this for?  Is a module missing a
> >  dependency?
> 
> It's for legacy parallel port, yes. Nobody will fix the kernel. Not
> sure why we needed it and you don't. You have that as a loadable
> module?
> 
Figured it out, it's loaded by our "cups" init script.  *sigh*

Clearly we need this, then I can eliminate a non-udev call to modprobe.

> > rules/packages/40-isdn.rules:
> >
> >  - SUBSYSTEM=="capi", KERNEL=="capi", NAME="capi20", \
> >  -         SYMLINK+="isdn/capi20", GROUP="uucp"
> >  + SUBSYSTEM=="capi", KERNEL=="capi", NAME="capi20", \
> >  +         GROUP="uucp"
> >
> >  What uses the /dev/isdn/capi20 symlink?  We've never had that, and
> >  I've never had any bug reports.
> 
> The old ISDN drivers are pretty much dead. But I've seen bugs about
> /dev/capi20, and it seems used:
>   http://www.google.com/codesearch?hl=en&sa=N&q=/dev/capi20++lang:c&ct=rr&cs_r=lang:c
> 
Right, but is /dev/isdn/capi20 used?  We don't have that symlink right
now, just /dev/capi20

(Nit-picky, I know, but the fewer symlinks and the more fixed software
the better! :p)

[dialout]
> If we can not agree on a default, we can do an option, but we do
> nobody a favor who works on an upstream project and who needs to find
> the differences again. So, I'm all for finding a common solution, For
> me it would not be a problem to use "dialout" if that is what we want.
> Harald?
> 
There's enough legacy stuff in Debian and Ubuntu that assumes dialout
(the entire PPP script maintenance, etc.) that I wouldn't want to use
uucp for it -- especially since dialout is a more descriptive group
anyway.

Scott
-- 
Scott James Remnant
scott@ubuntu.com

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

Re: Moving Ubuntu to upstream udev rules (Part 2)

[Kay Sievers]

On Mon, Dec 22, 2008 at 17:02, Scott James Remnant <scott@ubuntu.com> wrote:
> On Mon, 2008-12-22 at 16:30 +0100, Kay Sievers wrote:

>> >  Isn't the ignore_remove already handled by the /lib/udev/devices
>> >  check?  Our /dev/net/tun is in there.
>>
>> Yeah, because it sets NAME= earlier to place it in the subdirectory.
>> The current check only covers devices which have NAME= set.
>>
> Slightly confused.
>
> The general ignore_remove rule looks like:
>
> ACTION="remove", NAME="?*", TEST="/lib/udev/devices/$name", \
>        OPTIONS+="ignore_remove"
>
> Does this mean that this rule does nothing if the name isn't changed?

Yes, it was like that until now.

> Want to understand where we need the ignore_remove option on rules, or
> what is caught by this one.

But the last line here, I added after you asked to check, should make
it work as expected:
  http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob;f=rules/rules.d/50-udev-default.rules;hÖfdf00bf9a26d6d7b76577b7d11eabdc1d9bebb;hb§cb7d79f787614b9c4ade94a7a95144ef46eacd

>> > rules/packages/40-isdn.rules:
>> >
>> >  - SUBSYSTEM="capi", KERNEL="capi", NAME="capi20", \
>> >  -         SYMLINK+="isdn/capi20", GROUP="uucp"
>> >  + SUBSYSTEM="capi", KERNEL="capi", NAME="capi20", \
>> >  +         GROUP="uucp"
>> >
>> >  What uses the /dev/isdn/capi20 symlink?  We've never had that, and
>> >  I've never had any bug reports.
>>
>> The old ISDN drivers are pretty much dead. But I've seen bugs about
>> /dev/capi20, and it seems used:
>>   http://www.google.com/codesearch?hl=en&sa=N&q=/dev/capi20++lang:c&ct=rr&cs_r=lang:c
>>
> Right, but is /dev/isdn/capi20 used?  We don't have that symlink right
> now, just /dev/capi20
>
> (Nit-picky, I know, but the fewer symlinks and the more fixed software
> the better! :p)

Ah, I mis-read, didn't catch the subdir link. Let's remove it. :)

> [dialout]
>> If we can not agree on a default, we can do an option, but we do
>> nobody a favor who works on an upstream project and who needs to find
>> the differences again. So, I'm all for finding a common solution, For
>> me it would not be a problem to use "dialout" if that is what we want.
>> Harald?
>>
> There's enough legacy stuff in Debian and Ubuntu that assumes dialout
> (the entire PPP script maintenance, etc.) that I wouldn't want to use
> uucp for it -- especially since dialout is a more descriptive group
> anyway.

Yeah, I like the dialout group better too. SUSE uses that too in some packages.

Kay

Re: Moving Ubuntu to upstream udev rules (Part 2)

[Marco d'Itri]

On Dec 22, Kay Sievers <kay.sievers@vrfy.org> wrote:

> >  - KERNEL="tun", NAME="net/%k", MODE="0666", OPTIONS+="ignore_remove"
> >  + KERNEL="tun", NAME="net/%k"
> >  The mode seems rather permissive?  Do you really allow any user to
> >  make tunnels by default?  (Ours is 0600!)
> Hmm, I don't know. I see Ubuntu users complaining on the net, who use
> virtualization not running as root. But if it's unsafe we should
> change that.
It's safe with modern kernels, it should be 666 to not anger users.

> >  We have the nvram group, no idea why, we just do ;)
> Hmm, if there is a good reason. Maybe just drop "nvram", and wait if
> anybody complains?
As I explained, it's a Debianism.

> Putting gigabyte-big USB hard disks in the "floppy" group? Also some
Yes, because "floopy" actually means "removable storage devices".

> ATA/SCSI storage controller are marked as removable. I don't think we
I like to call these "buggy".

> If we can not agree on a default, we can do an option, but we do
> nobody a favor who works on an upstream project and who needs to find
> the differences again. So, I'm all for finding a common solution, For
> me it would not be a problem to use "dialout" if that is what we want.
> Harald?
In Debian uucp and dialout are totally unrelated groups: the first one
is used by the Taylor UUCP package for its own stuff, the second one
means "member users can initiate a dialout connection using SLIP,
PPP or a terminal program". I think some distributions overloaded the
uucp group with both meanings. Debian cannot merge them.

-- 
ciao,
Marco

Re: Moving Ubuntu to upstream udev rules (Part 2)

[Kay Sievers]

On Mon, Dec 22, 2008 at 17:15, Marco d'Itri <md@linux.it> wrote:
> On Dec 22, Kay Sievers <kay.sievers@vrfy.org> wrote:
>
>> >  - KERNEL="tun", NAME="net/%k", MODE="0666", OPTIONS+="ignore_remove"
>> >  + KERNEL="tun", NAME="net/%k"
>> >  The mode seems rather permissive?  Do you really allow any user to
>> >  make tunnels by default?  (Ours is 0600!)
>> Hmm, I don't know. I see Ubuntu users complaining on the net, who use
>> virtualization not running as root. But if it's unsafe we should
>> change that.
> It's safe with modern kernels, it should be 666 to not anger users.
>
>> >  We have the nvram group, no idea why, we just do ;)
>> Hmm, if there is a good reason. Maybe just drop "nvram", and wait if
>> anybody complains?
> As I explained, it's a Debianism.

Yeah, fine, distros who need that can just add it, if it's not
"generally useful".

>> Putting gigabyte-big USB hard disks in the "floppy" group? Also some
> Yes, because "floopy" actually means "removable storage devices".

Yeah, but it is a weird assupmtion today. We have real devices today
on USB and not only floppy-like USB sticks.

>> ATA/SCSI storage controller are marked as removable. I don't think we
> I like to call these "buggy".

Hmm, with buses like SAS, SATA, and enclosures, non-removable devices
are really going away. Today almost all stuff can be moved around, and
is removable. Some devices need that to force re-validation on open.

>> If we can not agree on a default, we can do an option, but we do
>> nobody a favor who works on an upstream project and who needs to find
>> the differences again. So, I'm all for finding a common solution, For
>> me it would not be a problem to use "dialout" if that is what we want.
>> Harald?
> In Debian uucp and dialout are totally unrelated groups: the first one
> is used by the Taylor UUCP package for its own stuff, the second one
> means "member users can initiate a dialout connection using SLIP,
> PPP or a terminal program". I think some distributions overloaded the
> uucp group with both meanings. Debian cannot merge them.

Yep, I guess we will all go for "dialout", where it fits better and
"uucp" is used to today.

Kay

Re: Moving Ubuntu to upstream udev rules (Part 2)

[Marco d'Itri]

On Dec 22, Kay Sievers <kay.sievers@vrfy.org> wrote:

> Yeah, but it is a weird assupmtion today. We have real devices today
> on USB and not only floppy-like USB sticks.
They are still removable.

-- 
ciao,
Marco

Re: Moving Ubuntu to upstream udev rules (Part 2)

[Kay Sievers]

On Mon, Dec 22, 2008 at 17:40, Marco d'Itri <md@linux.it> wrote:
> On Dec 22, Kay Sievers <kay.sievers@vrfy.org> wrote:
>
>> Yeah, but it is a weird assupmtion today. We have real devices today
>> on USB and not only floppy-like USB sticks.
> They are still removable.

Sure!. What I'm saying is that they are still in no way close to
floppies, and should therefore not be in the floppy group.

Thanks,
Kay

Re: Moving Ubuntu to upstream udev rules (Part 2)

[Piter PUNK]

Kay Sievers wrote:
> On Mon, Dec 22, 2008 at 15:20, Scott James Remnant <scott@ubuntu.com> wrote:
>>  - SUBSYSTEM="block", GROUP="disk"
>>  + SUBSYSTEM="block", ATTRS{removable}!="1", GROUP="disk"
>>  + SUBSYSTEM="block", ATTRS{removable}="1", GROUP="floppy"
>>
>>  We put removable block devices in the floppy group, you leave them in
>>  disk?  (But use the floppy group for real floppies?)
> 
> Putting gigabyte-big USB hard disks in the "floppy" group? Also some
> ATA/SCSI storage controller are marked as removable. I don't think we
> want that in the defaults. :)

Here we put floppies in "floppy" group and other removable devices
on "plugdev" group.

>>  - KERNEL="sg[0-9]*", ATTRS{type}!="3|6", GROUP="disk", MODE="0640"
>>  + SUBSYSTEMS="scsi", ATTRS{type}="0", GROUP="disk", MODE="0640"
>>  + SUBSYSTEMS="scsi", ATTRS{type}="4|5", GROUP="cdrom", MODE="0640"
> 
> We do not use "cdrom", but we could. Harald?

Oh! And CD/CD-R/CD-RW/DVD/DVD-* in "cdrom" group

>>  - KERNEL="pktcdvd[0-9]*",        NAME="pktcdvd/%k"
>>  + KERNEL="pktcdvd[0-9]*",        NAME="pktcdvd/%k", GROUP="cdrom"
> 
> Harald, you have "cdrom", and that's fine ot use?

Those are in "cdrom", too.

>>  We put CD-ROM drives and similar into the cdrom group, not disk.
>>
>>  + SUBSYSTEMS="scsi", ATTRS{type}="1|8", GROUP="tape"
>>
>>  - KERNEL="ht[0-9]*|nht[0-9]*",   GROUP="disk"
>>  + KERNEL="ht[0-9]*|nht[0-9]*",   GROUP="tape"
>>
>>  - KERNEL="pt[0-9]*|npt[0-9]*",   GROUP="disk"
>>  + KERNEL="pt[0-9]*|npt[0-9]*",   GROUP="tape"
>>
>>  - KERNEL="qft[0-9]*|nqft[0-9]*|zqft[0-9]*|nzqft[0-9]*|rawqft[0-9]*|
>>    nrawqft[0-9]*", GROUP="disk"
>>  + KERNEL="qft[0-9]*|nqft[0-9]*|zqft[0-9]*|nzqft[0-9]*|rawqft[0-9]*|
>>    nrawqft[0-9]*", GROUP="tape"
>>
>>  We put tape drives and similar into the tape group, not disk.
> 
> Hmm, we don't have a "tape" group at all. Harald you have?

Here we have the group "tape" but no rule to assign anything to
this group.

> Not sure. Removed it! /dev/audio should just be just removed from the kernel.
> 
>>  + SUBSYSTEM="sound",                     GROUP="audio"
>>
>>  And we have an "audio" group for them.
> 
> Added. Harald, could you please check, that you get an "audio" group
> too. It's as useful as "video", even when we do not put any "normal"
> users, but only daemons in it.

We have that here, too.

> If we can not agree on a default, we can do an option, but we do
> nobody a favor who works on an upstream project and who needs to find
> the differences again. So, I'm all for finding a common solution, For
> me it would not be a problem to use "dialout" if that is what we want.
> Harald?

"uucp" group is in use here... No "dialout" group.
This is really needed?

Piter PUNK

Re: Moving Ubuntu to upstream udev rules (Part 2)

[Marco d'Itri]

On Dec 22, Piter PUNK <piterpunk@unitednerds.org> wrote:

> "uucp" group is in use here... No "dialout" group.
> This is really needed?
It really is, at least if you want to have a non-insecure UUCP package
(I do).

-- 
ciao,
Marco

Re: Moving Ubuntu to upstream udev rules (Part 2)

[Kay Sievers]

On Mon, Dec 22, 2008 at 17:02, Scott James Remnant <scott@ubuntu.com> wrote:
> On Mon, 2008-12-22 at 16:30 +0100, Kay Sievers wrote:
>> On Mon, Dec 22, 2008 at 15:20, Scott James Remnant <scott@ubuntu.com> wrote:
>> >  This will still be difficult for me to upload with ;)
>> >
>> >  - SUBSYSTEM="block", KERNEL="sr[0-9]*", SYMLINK+="scd%n"
>> >  + SUBSYSTEM="block", KERNEL="sr[0-9]*", NAME="scd%n", SYMLINK+="%k"
>> >
>> >  I still think we have this round the right way! :-)
>>
>> devices.txt is in no way "right" for everything, that section is from
>> the 2.4 days, and may not mean anything today. I'll wait for the SCSI
>> guys to tell. We should not switch names if there will never be a scd*
>> device in the kernel, because that would mean that sr* is the default,
>> and scd* is the legacy. I'll come back as soon as I got an answer.
>>
> No problem, will wait for that :)

Got the answers. The block layer and the SCSI maintainer see the
kernel name sr* as the default today, and /dev/scd* as a compat link.

If anybody cares about devices.txt, this section should just be removed.

Thanks,
Kay