Moving Ubuntu to upstream udev rules

Moving Ubuntu to upstream udev rules

[Scott James Remnant]

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

Have been going through our udev rules and comparing them to those in
the package as the upstream rules, and have noted about a page of things
either we need to change or need to change in the upstream rules.

Some of these I care about, some of them I'm not fussed - but we should
at least chat about them.


modprobe called without -b:

  without -b, the modprobe calls in udev are not checked against the
  blacklist, making it damned hard to disable automatic module loading

  please add -b to the modprobe calls.


ide-scsi

  discussed on IRC, DO NOT WANT


ch

  this scsi driver (tape changers) is missing a modalias, the following
  rule is needed to load it (or a kernel patch):

    SUBSYSTEM=="scsi", ATTR{type}=="8", RUN+="/sbin/modprobe -b ch"


tifm

  your rules are less careful than ours, we do:

    SUBSYSTEM=="tifm", ENV{TIFM_CARD_TYPE}=="SD", RUN+="/sbin/modprobe
-b tifm_sd"
    SUBSYSTEM=="tifm", ENV{TIFM_CARD_TYPE}=="MS", RUN+="/sbin/modprobe
-b tifm_ms"


firmware

  if we don't copy the default rules into the initramfs (to get around
  the many GROUP= in there), we still need to load firmware.

  could this rule be separated out into a different file?


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%
n"


rtc

  our rtc rules are more careful about only symlinking the CMOS
  to /dev/rtc:

    SUBSYSTEM=="rtc", DRIVERS=="rtc_cmos", SYMLINK+="rtc"

  additionally, we place these in the "audio" group

    SUBSYSTEM=="rtc", GROUP="audio"


dv1394

  I couldn't work out why you symlink the kernelish names to their
  proper names, should this not be:

    KERNEL=="dv1394*", NAME="dv1394/%n"


raw1394

  This should be in the "disk" group, not the "video" group; it can be
  used to execute code as root


names

  you rename some devices and disagree with devices.txt

    rawctl -> raw/rawctl

  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"

    KERNEL=="device-mapper", NAME="mapper/control"

    KERNEL=="capi", NAME="capi20"
    KERNEL=="capi[0-9]*", NAME="capi/%n"

    KERNEL=="zapctl", NAME="zap/ctl"
    KERNEL=="zaptimer", NAME="zap/timer"
    KERNEL=="zapchannel", NAME="zap/channel"
    KERNEL=="zappseudo", NAME="zap/pseudo"
    KERNEL=="zap[0-9]*", NAME="zap/%n"


symlinks

  you have lots of extra symlinks, any particular reason?  are you paid
  by the symlink? :p

    X0R -> null		??!! WTF
    ramdisk -> ram0
    ram -> ram1
    lirc -> lirc0
    js* -> input/js*	- aren't these different kernel drivers?
    vbi -> vbi0
    radio -> radio0
    video -> video0
    fb -> fb0
    par* -> lp*		??
    ftape -> qft0
    hw_random -> hwrng	- we just rename, and don't symlink the old name
    sbpcd -> sbpcd0
    xpram* -> slram*
    sxctl -> specialix_sxctl	- shouldn't this be just a rename?
    rioctl -> specialix_rioctl	- shouldn't this be just a rename?
    
  no /dev/pilot? :)


permissions

  dri/card*	666	???!!!
  fuse		666	???!!!
  bus/usb/*	644	instead of 664?
  tty		620	instead of 600? your ttys are writable?


groups

  no cdrom group?
  no scanner group?
  no tape group?
  no dialout group?	- this may be Debianish, but we rely on it
  no audio group?

  ppdev devices not in the lp group?

  nvram in group kmem not nvram?


Scott
-- 
Scott James Remnant
scott@canonical.com

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

Re: Moving Ubuntu to upstream udev rules

[Kay Sievers]

On Fri, 2008-12-19 at 06:47 +0000, Scott James Remnant wrote:
> Have been going through our udev rules and comparing them to those in
> the package as the upstream rules, and have noted about a page of things
> either we need to change or need to change in the upstream rules.
> 
> Some of these I care about, some of them I'm not fussed - but we should
> at least chat about them.
> 
> 
> modprobe called without -b:
> 
>   without -b, the modprobe calls in udev are not checked against the
>   blacklist, making it damned hard to disable automatic module loading
> 
>   please add -b to the modprobe calls.

Done.

> ide-scsi
> 
>   discussed on IRC, DO NOT WANT

The driver is dead, and the rule removed.

> ch
> 
>   this scsi driver (tape changers) is missing a modalias, the following
>   rule is needed to load it (or a kernel patch):
> 
>     SUBSYSTEM="scsi", ATTR{type}="8", RUN+="/sbin/modprobe -b ch"

The ch module should get an alias:
  scsi:t-0x09*
instead. I added the rule for now, but it should be removed when it's in
the kernel.

> tifm
> 
>   your rules are less careful than ours, we do:
> 
>     SUBSYSTEM="tifm", ENV{TIFM_CARD_TYPE}="SD", RUN+="/sbin/modprobe
> -b tifm_sd"
>     SUBSYSTEM="tifm", ENV{TIFM_CARD_TYPE}="MS", RUN+="/sbin/modprobe
> -b tifm_ms"

Added. :)

> firmware
> 
>   if we don't copy the default rules into the initramfs (to get around
>   the many GROUP= in there), we still need to load firmware.
> 
>   could this rule be separated out into a different file?

Done.

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

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

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

> dv1394
> 
>   I couldn't work out why you symlink the kernelish names to their
>   proper names, should this not be:
> 
>     KERNEL="dv1394*", NAME="dv1394/%n"

Same here, there was no clear rule, and we seem to need both, and then
we usually do not switch names and links around if we have both anyway.

But I don't mind here to do that, this driver is almost dead anyway, and
will go some day.

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

> names
> 
>   you rename some devices and disagree with devices.txt
> 
>     rawctl -> raw/rawctl

The tools use that, if  I remember. Someone maintaining the tools should
tell, devices.txt is pretty unreliable sometimes.

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

>     KERNEL="device-mapper", NAME="mapper/control"

It's only in suse/64-device-mapper.rules, because upstream device-mapper
does not integrate with udev. The rules belong into the dmsetup package.

Ubuntu carries the "dmsetup export" patch, so I have no problem moving a
copy to the packages directory, and let the Red Hat guys find out when
they want to fix their stuff. :) 

>     KERNEL="capi", NAME="capi20"
>     KERNEL="capi[0-9]*", NAME="capi/%n"

It's in the packages/40-isdn.rules rules, they are installed with the
ISDN tools.

>     KERNEL="zapctl", NAME="zap/ctl"
>     KERNEL="zaptimer", NAME="zap/timer"
>     KERNEL="zapchannel", NAME="zap/channel"
>     KERNEL="zappseudo", NAME="zap/pseudo"
>     KERNEL="zap[0-9]*", NAME="zap/%n"

That driver is dead, and renamed to something else. These rules are in:
packages/40-zaptel.rules though.

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

>     ramdisk -> ram0
>     ram -> ram1
>     lirc -> lirc0
>     js* -> input/js*	- aren't these different kernel drivers?

I have no idea. Maybe remove them? Harald?

>     vbi -> vbi0
>     radio -> radio0
>     video -> video0

That is needed for some old tools. People have complained.

>     fb -> fb0
>     par* -> lp*		??
>     ftape -> qft0

No idea. Harald?

>     hw_random -> hwrng	- we just rename, and don't symlink the old name

Sounds fine.

>     sbpcd -> sbpcd0
>     xpram* -> slram*

No idea, never seen. Remove it and wait for someone to complain? Harald?

>     sxctl -> specialix_sxctl	- shouldn't this be just a rename?
>     rioctl -> specialix_rioctl	- shouldn't this be just a rename?

Maybe just rename it, yeah.

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

> permissions
> 
>   dri/card*	666	???!!!
>   fuse		666	???!!!

No idea.

>   bus/usb/*	644	instead of 664?

We intentionally don't do group assignment here, so we can change the
permission if you need it.

>   tty		620	instead of 600? your ttys are writable?

No idea. Just change it?

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

>   no audio group?

This group is used in alsa rules.

>   ppdev devices not in the lp group?

Sounds like they should.

>   nvram in group kmem not nvram?

No idea what's "right" here.



I changed some things and pushed it out to git.

Care to check the list again, and collect the remaining things for the
next step? Then we can check with Harald what we can remove or change?

Thanks for doing this, looking forward to a more unified setup!

Thanks,
Kay

Re: Moving Ubuntu to upstream udev rules

[Marco d'Itri]

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

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

> >   tty		620	instead of 600? your ttys are writable?
> No idea. Just change it?
It depends if you like write(1) and wall(1) to work by default or not.
I do.

-- 
ciao,
Marco

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Moving Ubuntu to upstream udev rules

[Piter PUNK]

Kay Sievers wrote:
> On Fri, 2008-12-19 at 06:47 +0000, Scott James Remnant wrote:
>>   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. :)

Only to know... why rtc in "audio" group?

>>     ramdisk -> ram0
>>     js* -> input/js*	- aren't these different kernel drivers?
> 
> I have no idea. Maybe remove them? Harald?

ramdisk -> ram0 --> link is on devices.txt
js -> input/js  --> probably is wrong. js and input/js are from
		    different drivers

>>     ftape -> qft0

devices.txt

>> permissions
>> 
>>   dri/card*	666	???!!!

I think this is overwrited by xorg.conf setting i don't have any
rule changing this permission and ther permissions here are 660:

crw-rw---- 1 root video 226, 0 2008-12-20 03:33 /dev/dri/card0

I guess 660 is the default of Xorg without an Mode directive
in DRI section in xorg.conf. The "video" group here is from
one of few slackware custom rules. (maybe another one that
can vanishes in the air?)

>>   tty		620	instead of 600? your ttys are writable?
> 
> No idea. Just change it?

good to use "wall" and "write".

>> groups
>
>>   no dialout group?	- this may be Debianish, but we rely on it
>>   nvram in group kmem not nvram?

Hmmmm... no dialout and no nvram group here.
nvram really needs an exclusive group?

> Thanks for doing this, lookingm forward to a more unified setup!

Closer and closer -:)

Piter PUNK

Re: Moving Ubuntu to upstream udev rules

[Robby Workman]

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

On Sat, 20 Dec 2008 06:12:52 -0200
Piter PUNK <piterpunk@unitednerds.org> wrote:

> >> permissions
> >> 
> >>   dri/card*	666	???!!!
> 
> I think this is overwrited by xorg.conf setting i don't have any
> rule changing this permission and ther permissions here are 660:
> 
> crw-rw---- 1 root video 226, 0 2008-12-20 03:33 /dev/dri/card0
> 
> I guess 660 is the default of Xorg without an Mode directive
> in DRI section in xorg.conf. The "video" group here is from
> one of few slackware custom rules. (maybe another one that
> can vanishes in the air?)


Yes, at least one other distribution mentioned a "video" group, so
maybe that is a candidate for upstream :)


> >>   no dialout group?	- this may be Debianish, but we rely on
> >> it nvram in group kmem not nvram?
> 
> Hmmmm... no dialout and no nvram group here.
> nvram really needs an exclusive group?


We use uucp in lieu of dialout iirc.  Ultimately though, this is easy
enough to work around as long as distributions know what the upstream
default is *and* that default doesn't change...

Re nvram group, I don't see why it shouldn't be root or kmem - is
there a legitimate reason why a normal user should have write access
to /dev/nvram?

-RW

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Moving Ubuntu to upstream udev rules

[Marco d'Itri]

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

> Only to know... why rtc in "audio" group?
Because it was needed by mplayer and it's a good approximation of users
with local console access.

> Re nvram group, I don't see why it shouldn't be root or kmem - is
> there a legitimate reason why a normal user should have write access
> to /dev/nvram?
I remember some thinkpad-specific application, for a start.

-- 
ciao,
Marco

Re: Moving Ubuntu to upstream udev rules

[Dan Nicholson]

On Sat, Dec 20, 2008 at 12:12 AM, Piter PUNK <piterpunk@unitednerds.org> wrote:
> Kay Sievers wrote:
>>
>> On Fri, 2008-12-19 at 06:47 +0000, Scott James Remnant wrote:
>
>>> permissions
>>>
>>>  dri/card*     666     ???!!!
>
> I think this is overwrited by xorg.conf setting i don't have any
> rule changing this permission and ther permissions here are 660:
>
> crw-rw---- 1 root video 226, 0 2008-12-20 03:33 /dev/dri/card0
>
> I guess 660 is the default of Xorg without an Mode directive
> in DRI section in xorg.conf. The "video" group here is from
> one of few slackware custom rules. (maybe another one that
> can vanishes in the air?)

It's actually libdrm that creates this node on behalf of Xorg.
However, newer libdrm releases can be built with --enable-udev so that
they just wait for the node to show up from udev and don't change the
mode/owner at all. If that configuration is not used or the node
doesn't show up from udev, the default in libdrm is root:root 660.

--
Dan

Re: Moving Ubuntu to upstream udev rules

[Kay Sievers]

On Fri, Dec 19, 2008 at 17:10, Marco d'Itri <md@linux.it> wrote:
> On Dec 19, Kay Sievers <kay.sievers@vrfy.org> wrote:
>
>> >   tty               620     instead of 600? your ttys are writable?
>> No idea. Just change it?
> It depends if you like write(1) and wall(1) to work by default or not.
> I do.

Doesn't wall use /dev/pts*?

Kay

Re: Moving Ubuntu to upstream udev rules

[Kay Sievers]

On Sat, Dec 20, 2008 at 12:30, Marco d'Itri <md@linux.it> wrote:
> On Dec 20, Piter PUNK <piterpunk@unitednerds.org> wrote:
>
>> Only to know... why rtc in "audio" group?
> Because it was needed by mplayer and it's a good approximation of users
> with local console access.

We do want to "approximate" local console access. There is
infrastructure in place today that does that properly. If that's the
only reason, we should not add it to the default rules.

>> Re nvram group, I don't see why it shouldn't be root or kmem - is
>> there a legitimate reason why a normal user should have write access
>> to /dev/nvram?
> I remember some thinkpad-specific application, for a start.

That was before the proper kernel drivers, right?

Thanks,
Kay

Re: Moving Ubuntu to upstream udev rules

[Kay Sievers]

On Fri, Dec 19, 2008 at 17:03, Kay Sievers <kay.sievers@vrfy.org> wrote:
> I changed some things and pushed it out to git.
>
> Care to check the list again, and collect the remaining things for the
> next step? Then we can check with Harald what we can remove or change?

I pushed out more stuff. Here is what I have left from your list, what
we should decide to do with. Care to check, if anything else is
missing?

# is it /devsr0 or /dev/sdc0?
SUBSYSTEM="block", KERNEL="sr[0-9]*", NAME="scd%n", SYMLINK+="sr%

# rtc in group "audio"?
SUBSYSTEM="rtc", GROUP="audio"

# is this a locally exploitable, or only a possibly firewire connected
remote machine?
raw1394 GROUP="video"

# which ones do we need, not need?
X0R -> null
ramdisk -> ram0
ram -> ram1
lirc -> lirc0
vbi -> vbi0
radio -> radio0
video -> video0
fb -> fb0
ftape -> qft0
sbpcd -> sbpcd0
xpram* -> slram*

# group nvram needed?
nvram GROUP="nvram"

# what are the right permissions?
fuse GROUP="666"
tty[0-9]* GROUP="600"

Thanks,
Kay

Re: Moving Ubuntu to upstream udev rules

[Marco d'Itri]

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

> >> >   tty               620     instead of 600? your ttys are writable?
> >> No idea. Just change it?
> > It depends if you like write(1) and wall(1) to work by default or not.
> > I do.
> Doesn't wall use /dev/pts*?
Not if you are using the system console.

> >> Re nvram group, I don't see why it shouldn't be root or kmem - is
> >> there a legitimate reason why a normal user should have write access
> >> to /dev/nvram?
> > I remember some thinkpad-specific application, for a start.
> That was before the proper kernel drivers, right?
Not sure.

-- 
ciao,
Marco

Re: Moving Ubuntu to upstream udev rules

[Kay Sievers]

On Sun, Dec 21, 2008 at 14:07, Marco d'Itri <md@linux.it> wrote:
> On Dec 21, Kay Sievers <kay.sievers@vrfy.org> wrote:
>> >> >   tty               620     instead of 600? your ttys are writable?
>> >> No idea. Just change it?
>> > It depends if you like write(1) and wall(1) to work by default or not.
>> > I do.
>> Doesn't wall use /dev/pts*?
> Not if you are using the system console.

Ah, fine.

  execve("/usr/bin/wall", ["wall"], [/* 57 vars */]) = 0
  ...
  open("/dev/tty1", O_WRONLY|O_NONBLOCK)  = 4
  writev(4, ...
  ...

Thanks,
Kay

Re: Moving Ubuntu to upstream udev rules

[Piter PUNK]

Kay Sievers wrote:
> On Fri, Dec 19, 2008 at 17:03, Kay Sievers <kay.sievers@vrfy.org> wrote:
> # is it /devsr0 or /dev/sdc0?
> SUBSYSTEM="block", KERNEL="sr[0-9]*", NAME="scd%n", SYMLINK+="sr%

I think it's OK. From devices.txt:

---
The prefix /dev/sr (instead of /dev/scd) has been deprecated.
( ... )
(in recommended links)
/dev/scd?       sr?             hard            Alternate SCSI CD-ROM name
---

The recommendation is to have a hardlink here. But i think symlink is OK.

> # rtc in group "audio"?
> SUBSYSTEM="rtc", GROUP="audio"

To me, this is still very bizarre.

> # which ones do we need, not need?
+ X0R -> null
+ ramdisk -> ram0
o ram -> ram1
x lirc -> lirc0
x vbi -> vbi0
+ radio -> radio0
x video -> video0
x fb -> fb0
+ ftape -> qft0
x sbpcd -> sbpcd0
o xpram* -> slram*

The ones with + are from devices.txt.

The links mark with x I thought they can still
be there. Is common to point the /dev/foo symlink
to the current /dev/fooN that's in use (usually
the first one, foo0). If user don't wants these links
he can always overwrite those links with custom rules
in /etc/udev/rules.d.

I don't know about the ones I mark with o.

> # group nvram needed?
> nvram GROUP="nvram"
> 
> # what are the right permissions?
> fuse GROUP="666"
> tty[0-9]* GROUP="600"

I like tty with MODE="0620". But 600 isn't bad.

The udev rules shipped with fuse-2.7.4 have
MODE="0666" in there. Maybe isn't better to leave
this to fuse package?

Piter PUNK

Re: Moving Ubuntu to upstream udev rules

[Kay Sievers]

On Sun, Dec 21, 2008 at 22:52, Piter PUNK <piterpunk@unitednerds.org> wrote:
> Kay Sievers wrote:
>>
>> On Fri, Dec 19, 2008 at 17:03, Kay Sievers <kay.sievers@vrfy.org> wrote:
>> # is it /devsr0 or /dev/sdc0?
>> SUBSYSTEM="block", KERNEL="sr[0-9]*", NAME="scd%n", SYMLINK+="sr%
>
> I think it's OK. From devices.txt:
>
> ---
> The prefix /dev/sr (instead of /dev/scd) has been deprecated.
> ( ... )
> (in recommended links)
> /dev/scd?       sr?             hard            Alternate SCSI CD-ROM name
> ---
>
> The recommendation is to have a hardlink here. But i think symlink is OK.

Devices.txt is pretty much ummaintained. If there will never a scd*
kernel name in the future, wich replaces the sr* nodes, then there
would be no real point in changing the kernel name here, just to cope
with an outdated document. :) We should ask the SCSI guys what they
recommend, have in mind here.

>> # rtc in group "audio"?
>> SUBSYSTEM="rtc", GROUP="audio"
>
> To me, this is still very bizarre.

Yeah, it seem like a hack to work around some issues. No normal user
should be in the "audio" group in the first place, because you really
don't want people logged in over ssh to listen to your microphone and
anything like that.

>> # which ones do we need, not need?
>
> + X0R -> null
> + ramdisk -> ram0
> o ram -> ram1
> x lirc -> lirc0
> x vbi -> vbi0
> + radio -> radio0
> x video -> video0
> x fb -> fb0
> + ftape -> qft0
> x sbpcd -> sbpcd0
> o xpram* -> slram*
>
> The ones with + are from devices.txt.
>
> The links mark with x I thought they can still
> be there. Is common to point the /dev/foo symlink
> to the current /dev/fooN that's in use (usually
> the first one, foo0). If user don't wants these links
> he can always overwrite those links with custom rules
> in /etc/udev/rules.d.
>
> I don't know about the ones I mark with o.

The stuff we don't know about, we should probably remove and wait if
anybody uses it. :)

>> # group nvram needed?
>> nvram GROUP="nvram"
>>
>> # what are the right permissions?
>> fuse GROUP="666"
>> tty[0-9]* GROUP="600"
>
> I like tty with MODE="0620". But 600 isn't bad.

0620 sounds fine, if people use the "tty" group.

> The udev rules shipped with fuse-2.7.4 have
> MODE="0666" in there. Maybe isn't better to leave
> this to fuse package?

Yeah, makes sense to leave that to the fuse tools.

Kay

Re: Moving Ubuntu to upstream udev rules

[Harald Hoyer]

Kay Sievers wrote:
 > # which ones do we need, not need?
 > X0R -> null
 > ramdisk -> ram0
 > ram -> ram1
 > lirc -> lirc0
 > vbi -> vbi0
 > radio -> radio0
 > video -> video0
 > fb -> fb0
 > ftape -> qft0
 > sbpcd -> sbpcd0
 > xpram* -> slram*

probably should be removed to identify crufty old software

Re: Moving Ubuntu to upstream udev rules

[Harald Hoyer]

Kay Sievers wrote:
> On Fri, Dec 19, 2008 at 17:03, Kay Sievers <kay.sievers@vrfy.org> wrote:
>> I changed some things and pushed it out to git.
>>
>> Care to check the list again, and collect the remaining things for the
>> next step? Then we can check with Harald what we can remove or change?
> 
> I pushed out more stuff. Here is what I have left from your list, what
> we should decide to do with. Care to check, if anything else is
> missing?
> 
> # is it /devsr0 or /dev/sdc0?
> SUBSYSTEM="block", KERNEL="sr[0-9]*", NAME="scd%n", SYMLINK+="sr%

scd0, because as stated in:
devices.txt: "The prefix /dev/sr (instead of /dev/scd) has been deprecated."

> 
> # rtc in group "audio"?
> SUBSYSTEM="rtc", GROUP="audio"

hmm, we still have no audio group and rtc has nothing to do with audio at all.

> # group nvram needed?
> nvram GROUP="nvram"

We have no nvram group and nobody complained about it in years :)

> 
> # what are the right permissions?
> fuse GROUP="666"

MODE\x0666 should be ok. It is a user space file system anybody should be able to 
use.

> tty[0-9]* GROUP="600"

with MODE\x0600, GROUP=tty would make no sense at all.

> 
> Thanks,
> Kay

Re: Moving Ubuntu to upstream udev rules

[Scott James Remnant]

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

Re: Moving Ubuntu to upstream udev rules

[Bernhard Walle]

* Kay Sievers [2008-12-21 13:53]:
>
> # rtc in group "audio"?
> SUBSYSTEM="rtc", GROUP="audio"

Could be because MPlayer tried to access the RTC.

  % mplayer -rtc /usr/share/sounds/KDE-Sys-App-Positive.ogg
  ...
  Linux RTC init error in ioctl (rtc_irqp_set 1024): Permission denied
  Try adding "echo 1024 > /proc/sys/dev/rtc/max-user-freq" to your system startup scripts.
  ...

That '-rtc' was the default at some time.



Regards,
Bernhard

Re: Moving Ubuntu to upstream udev rules

[Marco d'Itri]

On Dec 22, Bernhard Walle <bernhard.walle@gmx.de> wrote:

> Could be because MPlayer tried to access the RTC.
Yes, at least for Debian I think this was the main reason.

-- 
ciao,
Marco

Re: Moving Ubuntu to upstream udev rules

[Kay Sievers]

On Mon, Dec 22, 2008 at 09:41, Harald Hoyer <harald@redhat.com> wrote:
> Kay Sievers wrote:
>> # which ones do we need, not need?
>> X0R -> null
>> ramdisk -> ram0
>> ram -> ram1
>> lirc -> lirc0
>> vbi -> vbi0
>> radio -> radio0
>> video -> video0
>> fb -> fb0
>> ftape -> qft0
>> sbpcd -> sbpcd0
>> xpram* -> slram*
>
> probably should be removed to identify crufty old software

I removed tham all. :)

Thanks,
Kay

Re: Moving Ubuntu to upstream udev rules

[Scott James Remnant]

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

On Mon, 2008-12-22 at 13:37 +0100, Kay Sievers wrote:

> I removed tham all. :)
> 
push ;)

Then I'll run through the package again, and see what else falls out.
Will you be able to do a 136 release to get us in sync?  That way I can
just package that.

Scott
-- 
Scott James Remnant
scott@canonical.com

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

Re: Moving Ubuntu to upstream udev rules

[Kay Sievers]

On Mon, Dec 22, 2008 at 09:53, Harald Hoyer <harald@redhat.com> wrote:
> Kay Sievers wrote:
>>
>> On Fri, Dec 19, 2008 at 17:03, Kay Sievers <kay.sievers@vrfy.org> wrote:
>>>
>>> I changed some things and pushed it out to git.
>>>
>>> Care to check the list again, and collect the remaining things for the
>>> next step? Then we can check with Harald what we can remove or change?
>>
>> I pushed out more stuff. Here is what I have left from your list, what
>> we should decide to do with. Care to check, if anything else is
>> missing?
>>
>> # is it /devsr0 or /dev/sdc0?
>> SUBSYSTEM="block", KERNEL="sr[0-9]*", NAME="scd%n", SYMLINK+="sr%
>
> scd0, because as stated in:
> devices.txt: "The prefix /dev/sr (instead of /dev/scd) has been deprecated."

That is a Linux 2.4 document. I'll go ask the SCSI guys, if there is
never a sdc* kernel device again, the document is just wrong, not the
rules. :)

Thanks,
Kay

Re: Moving Ubuntu to upstream udev rules

[Kay Sievers]

On Mon, Dec 22, 2008 at 13:39, Scott James Remnant <scott@canonical.com> wrote:
> On Mon, 2008-12-22 at 13:37 +0100, Kay Sievers wrote:
>
>> I removed tham all. :)
>>
> push ;)
>
> Then I'll run through the package again, and see what else falls out.
> Will you be able to do a 136 release to get us in sync?  That way I can
> just package that.

Sure, no problem. Let's get through the first round, then we do a new release.

Kay

Re: Moving Ubuntu to upstream udev rules

[Kay Sievers]

On Mon, Dec 22, 2008 at 12:57, Marco d'Itri <md@linux.it> wrote:
> On Dec 22, Bernhard Walle <bernhard.walle@gmx.de> wrote:
>
>> Could be because MPlayer tried to access the RTC.
> Yes, at least for Debian I think this was the main reason.

Yeah, likely the reason. But people it's a weird hack, and should that
on their box, and not the default rules.

Kay

Re: Moving Ubuntu to upstream udev rules

[Kay Sievers]

On Mon, Dec 22, 2008 at 10:39, Scott James Remnant <scott@canonical.com> 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

Re: Moving Ubuntu to upstream udev rules

[Karel Zak]

On Fri, Dec 19, 2008 at 05:03:52PM +0100, Kay Sievers wrote:
> > names
> > 
> >   you rename some devices and disagree with devices.txt
> > 
> >     rawctl -> raw/rawctl
> 
> The tools use that, if  I remember. Someone maintaining the tools should
> tell, devices.txt is pretty unreliable sometimes.

 The upstream raw(8) command supports /dev/rawctl and also
 /dev/raw/rawctl.  I think it makes more sense to use raw/rawctl when
 you have all your raw devices in raw/ subdirectory (e.g. /dev/raw/raw<N>).

    Karel

-- 
 Karel Zak  <kzak@redhat.com>

Re: Moving Ubuntu to upstream udev rules

[Kay Sievers]

On Fri, Dec 26, 2008 at 00:26, Karel Zak <kzak@redhat.com> wrote:
> On Fri, Dec 19, 2008 at 05:03:52PM +0100, Kay Sievers wrote:
>> > names
>> >
>> >   you rename some devices and disagree with devices.txt
>> >
>> >     rawctl -> raw/rawctl
>>
>> The tools use that, if  I remember. Someone maintaining the tools should
>> tell, devices.txt is pretty unreliable sometimes.
>
>  The upstream raw(8) command supports /dev/rawctl and also
>  /dev/raw/rawctl.  I think it makes more sense to use raw/rawctl when
>  you have all your raw devices in raw/ subdirectory (e.g. /dev/raw/raw<N>).

The raw tool looks for /dev/rawctl first and the fallback to
/dev/raw/rawctl is named DEVFS_*. Should we turn that order around and
remove the devfs notion from the raw tool and let udev create a
dev/raw/rawctl node?

Thanks,
Kay

Re: Moving Ubuntu to upstream udev rules

[Karel Zak]

On Fri, Dec 26, 2008 at 12:39:16AM +0100, Kay Sievers wrote:
> On Fri, Dec 26, 2008 at 00:26, Karel Zak <kzak@redhat.com> wrote:
> > On Fri, Dec 19, 2008 at 05:03:52PM +0100, Kay Sievers wrote:
> >> > names
> >> >
> >> >   you rename some devices and disagree with devices.txt
> >> >
> >> >     rawctl -> raw/rawctl
> >>
> >> The tools use that, if  I remember. Someone maintaining the tools should
> >> tell, devices.txt is pretty unreliable sometimes.
> >
> >  The upstream raw(8) command supports /dev/rawctl and also
> >  /dev/raw/rawctl.  I think it makes more sense to use raw/rawctl when
> >  you have all your raw devices in raw/ subdirectory (e.g. /dev/raw/raw<N>).
> 
> The raw tool looks for /dev/rawctl first and the fallback to
> /dev/raw/rawctl is named DEVFS_*. Should we turn that order around and
> remove the devfs notion from the raw tool and let udev create a
> dev/raw/rawctl node?

 Yeah. Fixed, committed and pushed.

 $ strace -e open ./raw
 open("/dev/raw/rawctl", O_RDWR)         = -1 ENOENT (No such file or directory)
 open("/dev/rawctl", O_RDWR)             = -1 ENOENT (No such file or directory)

 I have also removed the #ifdef OLD_RAW_DEVS (/dev/raw<N>) junk.


 BTW, it would be nice to refresh devices.txt according to your latest
 changes in udev.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>

Re: Moving Ubuntu to upstream udev rules

[Kay Sievers]

On Fri, Dec 26, 2008 at 01:26, Karel Zak <kzak@redhat.com> wrote:
> On Fri, Dec 26, 2008 at 12:39:16AM +0100, Kay Sievers wrote:
>> On Fri, Dec 26, 2008 at 00:26, Karel Zak <kzak@redhat.com> wrote:
>> > On Fri, Dec 19, 2008 at 05:03:52PM +0100, Kay Sievers wrote:
>> >> > names
>> >> >
>> >> >   you rename some devices and disagree with devices.txt
>> >> >
>> >> >     rawctl -> raw/rawctl
>> >>
>> >> The tools use that, if  I remember. Someone maintaining the tools should
>> >> tell, devices.txt is pretty unreliable sometimes.
>> >
>> >  The upstream raw(8) command supports /dev/rawctl and also
>> >  /dev/raw/rawctl.  I think it makes more sense to use raw/rawctl when
>> >  you have all your raw devices in raw/ subdirectory (e.g. /dev/raw/raw<N>).
>>
>> The raw tool looks for /dev/rawctl first and the fallback to
>> /dev/raw/rawctl is named DEVFS_*. Should we turn that order around and
>> remove the devfs notion from the raw tool and let udev create a
>> dev/raw/rawctl node?
>
>  Yeah. Fixed, committed and pushed.
>
>  $ strace -e open ./raw
>  open("/dev/raw/rawctl", O_RDWR)         = -1 ENOENT (No such file or directory)
>  open("/dev/rawctl", O_RDWR)             = -1 ENOENT (No such file or directory)
>
>  I have also removed the #ifdef OLD_RAW_DEVS (/dev/raw<N>) junk.

Pushed out /dev/raw/rawctl.

>  BTW, it would be nice to refresh devices.txt according to your latest
>  changes in udev.

Yeah, we should do that, also the /dev/scd* stuff should be removed there.

Thanks,
Kay