Mailing List Archive: [RFC] udev rules cleanup / merging rules files with other distros

[RFC] udev rules cleanup / merging rules files with other distros

Sep 4, 2007, 1:34 AM

Post #1 of 12 (264 views)

Hi there!

As you all know up to now we have our very own rules file 50-udev.rules
This is good for getting our specials - but bad from maintainance view.

So here we are:
In udev git-gtree suse and redhat rules are already merged.
But they use a different permission / group system than we have, they have
less groups and assign some desktop permissions via pam_console.

I also got all of our rules files (except 50-udev.rules) merged with what the
other distros use (already in git).

Slackware has already started merging the rules with this "upstream" common
rules, and they also are more near to our approach by using groups for
audio/tape/cdrom/...
But I have not yet seen their rules yet. So for now we are on our own.

So before doing to much work we should get a sane concept.
And for that concept we need:
* A (maybe formal) definition what each group should be used for
* what devices it contains (if not obvious)
* if permissions should be read/read-write for the group
* and nothing/read for world.

The question arises as we use MODE=660 for most groups but upstream does 640
most of the time.

This are the groups.
1. audio
All alsa and oss devices.
Rules are not contained in upstream rules - they will in future be installed
by media-libs/alsa-lib
And upstream split of file for also also does not contain this group
but sure it should keep MODE=660 / group audio
(Or should we still support oss without having alsa installed)

2. cdrom
Used for all cdrom/cdwriter devices and for scsi also the associated sg
device.
MODE=660
Upstream has no such group - member of disk for them.

3. cdrw
Only used for pktcdvd with MODE=660
Should this be merged into group cdrom?

4. disk
Contains every device with SUBSYSTEM==block, with MODE=660
the raw-devices (still needed?)
+ some devices needed for ata-over-ethernet (with modes 220 or 440)
Upstream uses MODE=640 (Like old unix group for backup usage).

5. floppy
The fd* devices, MODE=660
Upstream uses MODE=640

6. lp
Used for all *lp* and parport devices with MODE=660
Upstream uses it same way.

7. tape
Contains all tape devices with MODE=660.
Upstream has no such group - member of disk group.

8. tty
Same usage as upstream (maybe only very slight changes)

9. usb
Devices for libusb (/dev/bus/usb/...) with MODE=664.
+ legousbtower device
Upstream has no such group but has libusb stuff root:root with MODE=644

If default world permission is reading then every package changing permissions
here (like gphoto, iscan, sane) should also keep world-read I think!

10. uucp
serial devices, isdn and more for dialout usage MODE=660
Upstream uses it same way.

11. video
A lot of misc stuff: dri/card*, nvidia, 3dfx, framebuffer, ieee1394, v4l, dvb
with MODE=660
Upstream has no such group - they keep group at root and grant access via pam.

Groups we do not use yet:

12. kmem
Upstream uses it for /dev/mem /dev/kmem /dev/port with MODE=640
Should be ok to use - we have group=root, MODE=640 for now

Matthias

--
Matthias Schwarzott (zzam)
--
gentoo-dev@gentoo.org mailing list

Re: [RFC] udev rules cleanup / merging rules files with other distros [ In reply to ]

remi at gentoo

Sep 4, 2007, 9:54 PM

Post #2 of 12 (245 views)

Permalink

Maybe some of those groups could be merged (cdrom, cdrw) or dropped
(tape maybe?)

Having usb devices as root:root 644 is going to be a PITA if we don't
have something like a sane pam_console (one that doesn't change all /dev
nodes whenever someone logs in over ssh, like the one we used to have
did) or like ConsoleKit.

Cheers,

RÃ©mi
--
gentoo-dev@gentoo.org mailing list

Re: [RFC] udev rules cleanup / merging rules files with other distros [ In reply to ]

robbat2 at gentoo

Sep 5, 2007, 12:10 AM

Post #3 of 12 (266 views)

Permalink

On Tue, Sep 04, 2007 at 10:34:05AM +0200, Matthias Schwarzott wrote:
> So here we are:
> In udev git-gtree suse and redhat rules are already merged.
> But they use a different permission / group system than we have, they have
> less groups and assign some desktop permissions via pam_console.
Might want to talk to the Gentopia people, they were replacing the sucky
pam_console with ConsoleKit, which is a partial solution - there are
still Gentoo systems where neither pam_console nor ConsoleKit are
wanted.

> I also got all of our rules files (except 50-udev.rules) merged with what the
> other distros use (already in git).
>
> Slackware has already started merging the rules with this "upstream" common
> rules, and they also are more near to our approach by using groups for
> audio/tape/cdrom/...
> But I have not yet seen their rules yet. So for now we are on our own.
>
> So before doing to much work we should get a sane concept.
> And for that concept we need:
> * A (maybe formal) definition what each group should be used for
> * what devices it contains (if not obvious)
> * if permissions should be read/read-write for the group
> * and nothing/read for world.
>
> The question arises as we use MODE=660 for most groups but upstream does 640
> most of the time.
>
>
> This are the groups.
> 1. audio
> All alsa and oss devices.
> Rules are not contained in upstream rules - they will in future be installed
> by media-libs/alsa-lib
> And upstream split of file for also also does not contain this group
> but sure it should keep MODE=660 / group audio
> (Or should we still support oss without having alsa installed)
What is upstreams behavior with this? Will their alsa-lib install
something similar? I'm not up on ALSA stuff, does being in the audio
group mean I can play music?

> 2. cdrom
> Used for all cdrom/cdwriter devices and for scsi also the associated sg
> device.
> MODE=660
> Upstream has no such group - member of disk for them.
How does upstream deal with expecting users to use burners?
Plain CDROM mounting doesn't need the cdrom group, as /bin/mount is
setuid, however special operations on CDs (like readcd/readom) should
also be allowed to some users?

> 3. cdrw
> Only used for pktcdvd with MODE=660
> Should this be merged into group cdrom?
I think merge.

> 4. disk
> Contains every device with SUBSYSTEM==block, with MODE=660
> the raw-devices (still needed?)
> + some devices needed for ata-over-ethernet (with modes 220 or 440)
> Upstream uses MODE=640 (Like old unix group for backup usage).
The 'dump' backup case is the only one I'm aware of that's valid (and it
can use 640).
Why does ATAoE need user-level access? The 220/440 modes seem weird to
me.

> 5. floppy
> The fd* devices, MODE=660
> Upstream uses MODE=640
Same field as cdrom group.

> 6. lp
> Used for all *lp* and parport devices with MODE=660
> Upstream uses it same way.
Might be a place for scanner usage, but CUPs for modern printing runs as
a daemon, users should not need the lp access.

> 7. tape
> Contains all tape devices with MODE=660.
> Upstream has no such group - member of disk group.
You know my standpoint on tape. It's a critical group for app-backup.
I've actually got one further addition to it since we spoke yesterday,
making the relevant sg devices owned by the tape group.
That said, the backup usage of tape could be merged with disk - given
that backup may use both of them, and backup apps tend to run with a lot
of powers anyway (either as root for global FS access, or with the disk
group for running 'dump').

> 8. tty
> Same usage as upstream (maybe only very slight changes)
I don't know.

>
> 9. usb
> Devices for libusb (/dev/bus/usb/...) with MODE=664.
> + legousbtower device
> Upstream has no such group but has libusb stuff root:root with MODE=644
Look at the additional rules installed by NUT (70-nut-usbups.rules).
They all have the form of:
SYSFS{idVendor}=="0463", SYSFS{idProduct}=="ffff", MODE="664", GROUP="nut"
Thus the USB stuff should have a sane default, and then become more
empowered by custom udev rules per application.

> 10. uucp
> serial devices, isdn and more for dialout usage MODE=660
> Upstream uses it same way.
I don't know.

> 11. video
> A lot of misc stuff: dri/card*, nvidia, 3dfx, framebuffer, ieee1394, v4l, dvb
> with MODE=660
> Upstream has no such group - they keep group at root and grant access via pam.
I don't know.

> Groups we do not use yet:
> 12. kmem
> Upstream uses it for /dev/mem /dev/kmem /dev/port with MODE=640
> Should be ok to use - we have group=root, MODE=640 for now
Should be sane to add, iirc it's needed for kexec right?

--
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85

Re: [RFC] udev rules cleanup / merging rules files with other distros [ In reply to ]

antarus at gentoo

Sep 5, 2007, 1:34 AM

Post #4 of 12 (250 views)

Permalink

On 9/5/07, Robin H. Johnson <robbat2@gentoo.org> wrote:
> On Tue, Sep 04, 2007 at 10:34:05AM +0200, Matthias Schwarzott wrote:
> > So here we are:
> > In udev git-gtree suse and redhat rules are already merged.
> > But they use a different permission / group system than we have, they have
> > less groups and assign some desktop permissions via pam_console.
> Might want to talk to the Gentopia people, they were replacing the sucky
> pam_console with ConsoleKit, which is a partial solution - there are
> still Gentoo systems where neither pam_console nor ConsoleKit are
> wanted.
>
> > I also got all of our rules files (except 50-udev.rules) merged with what the
> > other distros use (already in git).
> >
> > Slackware has already started merging the rules with this "upstream" common
> > rules, and they also are more near to our approach by using groups for
> > audio/tape/cdrom/...
> > But I have not yet seen their rules yet. So for now we are on our own.
> >
> > So before doing to much work we should get a sane concept.
> > And for that concept we need:
> > * A (maybe formal) definition what each group should be used for
> > * what devices it contains (if not obvious)
> > * if permissions should be read/read-write for the group
> > * and nothing/read for world.
> >
> > The question arises as we use MODE=660 for most groups but upstream does 640
> > most of the time.
> >
> >
> > This are the groups.
> > 1. audio
> > All alsa and oss devices.
> > Rules are not contained in upstream rules - they will in future be installed
> > by media-libs/alsa-lib
> > And upstream split of file for also also does not contain this group
> > but sure it should keep MODE=660 / group audio
> > (Or should we still support oss without having alsa installed)
> What is upstreams behavior with this? Will their alsa-lib install
> something similar? I'm not up on ALSA stuff, does being in the audio
> group mean I can play music?
>
> > 2. cdrom
> > Used for all cdrom/cdwriter devices and for scsi also the associated sg
> > device.
> > MODE=660
> > Upstream has no such group - member of disk for them.
> How does upstream deal with expecting users to use burners?
> Plain CDROM mounting doesn't need the cdrom group, as /bin/mount is
> setuid, however special operations on CDs (like readcd/readom) should
> also be allowed to some users?
>
> > 3. cdrw
> > Only used for pktcdvd with MODE=660
> > Should this be merged into group cdrom?
> I think merge.
>
> > 4. disk
> > Contains every device with SUBSYSTEM==block, with MODE=660
> > the raw-devices (still needed?)
> > + some devices needed for ata-over-ethernet (with modes 220 or 440)
> > Upstream uses MODE=640 (Like old unix group for backup usage).
> The 'dump' backup case is the only one I'm aware of that's valid (and it
> can use 640).
> Why does ATAoE need user-level access? The 220/440 modes seem weird to
> me.
>
> > 5. floppy
> > The fd* devices, MODE=660
> > Upstream uses MODE=640
> Same field as cdrom group.
>
> > 6. lp
> > Used for all *lp* and parport devices with MODE=660
> > Upstream uses it same way.
> Might be a place for scanner usage, but CUPs for modern printing runs as
> a daemon, users should not need the lp access.

Because all of our users use cups...

>
> > 7. tape
> > Contains all tape devices with MODE=660.
> > Upstream has no such group - member of disk group.
> You know my standpoint on tape. It's a critical group for app-backup.
> I've actually got one further addition to it since we spoke yesterday,
> making the relevant sg devices owned by the tape group.
> That said, the backup usage of tape could be merged with disk - given
> that backup may use both of them, and backup apps tend to run with a lot
> of powers anyway (either as root for global FS access, or with the disk
> group for running 'dump').
>
> > 8. tty
> > Same usage as upstream (maybe only very slight changes)
> I don't know.
>
> >
> > 9. usb
> > Devices for libusb (/dev/bus/usb/...) with MODE=664.
> > + legousbtower device
> > Upstream has no such group but has libusb stuff root:root with MODE=644
> Look at the additional rules installed by NUT (70-nut-usbups.rules).
> They all have the form of:
> SYSFS{idVendor}=="0463", SYSFS{idProduct}=="ffff", MODE="664", GROUP="nut"
> Thus the USB stuff should have a sane default, and then become more
> empowered by custom udev rules per application.
>
> > 10. uucp
> > serial devices, isdn and more for dialout usage MODE=660
> > Upstream uses it same way.
> I don't know.
>
> > 11. video
> > A lot of misc stuff: dri/card*, nvidia, 3dfx, framebuffer, ieee1394, v4l, dvb
> > with MODE=660
> > Upstream has no such group - they keep group at root and grant access via pam.
> I don't know.
>
> > Groups we do not use yet:
> > 12. kmem
> > Upstream uses it for /dev/mem /dev/kmem /dev/port with MODE=640
> > Should be ok to use - we have group=root, MODE=640 for now
> Should be sane to add, iirc it's needed for kexec right?
>
> --
> Robin Hugh Johnson
> Gentoo Linux Developer & Infra Guy
> E-Mail : robbat2@gentoo.org
> GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
>
>
--
gentoo-dev@gentoo.org mailing list

Re: [RFC] udev rules cleanup / merging rules files with other distros [ In reply to ]

hd_brummy at gentoo

Sep 5, 2007, 1:54 AM

Post #5 of 12 (247 views)

Permalink

Guten Tag ,

am Mittwoch, 5. September 2007 um 10:34 schrieben Sie:

>> > 6. lp
>> > Used for all *lp* and parport devices with MODE=660
>> > Upstream uses it same way.
>> Might be a place for scanner usage, but CUPs for modern printing runs as
>> a daemon, users should not need the lp access.

> Because all of our users use cups...

vdr-graphlcd need this device...

--
Mit freundlichen Grüßen
Joerg Bornkessel
mailto:hd_brummy@gentoo.org

Re: [RFC] udev rules cleanup / merging rules files with other distros [ In reply to ]

zzam at gentoo

Sep 5, 2007, 2:38 AM

Post #6 of 12 (243 views)

Permalink

On Mittwoch, 5. September 2007, RÃ©mi Cardona wrote:
> Maybe some of those groups could be merged (cdrom, cdrw) or dropped
> (tape maybe?)
>
I guess this is ok, as for normal burning cdrom for now does grant all
permissions.
Only questionable thing is: Isn't a user with write permission to cdroms able
to modify firmware ... ?

> Having usb devices as root:root 644 is going to be a PITA if we don't
> have something like a sane pam_console (one that doesn't change all /dev
> nodes whenever someone logs in over ssh, like the one we used to have
> did) or like ConsoleKit.

I am not planning to delete group usb. I just want to discuss this permission
stuff and not decide alone.

For usb we sure keep GROUP=usb, MODE=664.
And for additionall packages maybe changed group, but still MODE=664.

Unlike most packages changing usb-permissions that now install MODE=660. I
should create a bug about this.

(Incomplete) list of affected packages:
media-libs/libgphoto2: GROUP="plugdev", MODE="660"
media-gfx/iscan: GROUP="scanner", MODE="660"
media-gfx/sane-backends: GROUP="scanner", MODE="660"

What about plugdev - should that name be changed?
Why is it used there? I remember it came from hal or similar.

Matthias

--
Matthias Schwarzott (zzam)
--
gentoo-dev@gentoo.org mailing list

Re: [RFC] udev rules cleanup / merging rules files with other distros [ In reply to ]

robbat2 at gentoo

Sep 5, 2007, 2:42 AM

Post #7 of 12 (248 views)

Permalink

On Wed, Sep 05, 2007 at 10:54:19AM +0200, Joerg Bornkessel wrote:
> Guten Tag ,
>
> am Mittwoch, 5. September 2007 um 10:34 schrieben Sie:
>
>
> >> > 6. lp
> >> > Used for all *lp* and parport devices with MODE=660
> >> > Upstream uses it same way.
> >> Might be a place for scanner usage, but CUPs for modern printing runs as
> >> a daemon, users should not need the lp access.
> > Because all of our users use cups...
> vdr-graphlcd need this device...
Ok, and I see that it asks a human to put the vdr user into the group.

--
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85

Re: [RFC] udev rules cleanup / merging rules files with other distros [ In reply to ]

1i5t5.duncan at cox

Sep 6, 2007, 3:33 AM

Post #8 of 12 (257 views)

Permalink

Matthias Schwarzott <zzam@gentoo.org> posted
200709051138.53143.zzam@gentoo.org, excerpted below, on Wed, 05 Sep 2007
11:38:52 +0200:

> On Mittwoch, 5. September 2007, RÃ©mi Cardona wrote:
>> Maybe some of those groups could be merged (cdrom, cdrw) or dropped
>> (tape maybe?)
>>
> I guess this is ok, as for normal burning cdrom for now does grant all
> permissions.
> Only questionable thing is: Isn't a user with write permission to cdroms
> able to modify firmware ... ?

There is... or used to be anyway... additional security implications
here. udev is close enough to the kernel that perhaps you know all about
the below and are already considering whatever implications remain in
current kernels, but if not, getting kernel and/or security involved in
this may be useful. I don't know what current status is on this, thus
the suggestion to involve security/kernel, but:

2.6.8 and CD recording (LWN.net, 2004, Aug 18)
http://lwn.net/Articles/98379/

SCSI command filtering (LWN.net, 2006, July 31)
http://lwn.net/Articles/193516/

The gist of which is that under certain circumstances, users with CD/DVD
write permissions may be able to scramble other SCSI devices as well.
With libata SCSI emulated SATA and PATA, that's potentially any hard
drive on a modern system. Shades of malware that holds your data for
ransom ("Wire me $1000 and I'll email you the unlock password."), anyone?

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

--
gentoo-dev@gentoo.org mailing list

Re: [RFC] Please test udev-115-r2 (was: udev rules cleanup / merging rules files with other distros) [ In reply to ]

zzam at gentoo

Sep 6, 2007, 7:49 AM

Post #9 of 12 (248 views)

Permalink

On Dienstag, 4. September 2007, Matthias Schwarzott wrote:

Hi there!

>
> So here we are:
> In udev git-gtree suse and redhat rules are already merged.
> But they use a different permission / group system than we have, they have
> less groups and assign some desktop permissions via pam_console.
>
> I also got all of our rules files (except 50-udev.rules) merged with what
> the other distros use (already in git).

That is already available as udev-115-r1 ebuild.

I now tried to get a small ruleset to apply additional to upstream ones to get
a sane status.

This is now available as (masked) ebuild udev-115-r2.
The files can also be browsed here: http://dev.gentoo.org/~zzam/udev/

I know not all rules have been copied from old rules. But are all really
needed?
Please test this ebuild and give feedback about wrong pathes/permissions for
devices.

Greetings
Matthias

--
Matthias Schwarzott (zzam)
--
gentoo-dev@gentoo.org mailing list

Re: Re: [RFC] udev rules cleanup / merging rules files with other distros [ In reply to ]

wolf31o2 at gentoo

Sep 6, 2007, 9:02 AM

Post #10 of 12 (269 views)

Permalink

On Thu, 2007-09-06 at 10:33 +0000, Duncan wrote:
> ransom ("Wire me $1000 and I'll email you the unlock password."), anyone?

Dammit! We weren't going to let anyone know about our business model
for 2007.1 and beyond. Thanks for ruining the fun...

--
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

Re: [RFC] Please test udev-115-r2 (was: udev rules cleanup / merging rules files with other distros) [ In reply to ]

zzam at gentoo

Sep 10, 2007, 11:37 AM

Post #11 of 12 (250 views)

Permalink

On Donnerstag, 6. September 2007, Matthias Schwarzott wrote:
> On Dienstag, 4. September 2007, Matthias Schwarzott wrote:

Hi there!

> That is already available as udev-115-r1 ebuild.
>
> I now tried to get a small ruleset to apply additional to upstream ones to
> get a sane status.
>
> This is now available as (masked) ebuild udev-115-r2.
> The files can also be browsed here: http://dev.gentoo.org/~zzam/udev/
>
> I know not all rules have been copied from old rules. But are all really
> needed?
> Please test this ebuild and give feedback about wrong pathes/permissions
> for devices.
>

I now did some more updates to udev-115-r2. This time it is about subdirs.
I removed /dev/fb/ as it does not play well together with
symlink /dev/fb -> /dev/fb0 (that upstream rules create now).
Same applies for /dev/lirc/ that we should also remove that from the lirc
rule.

Matthias

--
Matthias Schwarzott (zzam)
--
gentoo-dev@gentoo.org mailing list

Re: [RFC] udev rules cleanup / merging rules files with other distros [ In reply to ]

eva at gentoo

Sep 10, 2007, 1:10 PM

Post #12 of 12 (246 views)

Permalink

Le mercredi 05 septembre 2007 Ã 11:38 +0200, Matthias Schwarzott a
Ã©crit :
> > Having usb devices as root:root 644 is going to be a PITA if we don't
> > have something like a sane pam_console (one that doesn't change all /dev
> > nodes whenever someone logs in over ssh, like the one we used to have
> > did) or like ConsoleKit.
>
> I am not planning to delete group usb. I just want to discuss this permission
> stuff and not decide alone.

> For usb we sure keep GROUP=usb, MODE=664.
> And for additional packages maybe changed group, but still MODE=664.

> Unlike most packages changing usb-permissions that now install MODE=660. I
> should create a bug about this.
>
> (Incomplete) list of affected packages:
> media-libs/libgphoto2: GROUP="plugdev", MODE="660"
> media-gfx/iscan: GROUP="scanner", MODE="660"
> media-gfx/sane-backends: GROUP="scanner", MODE="660"

don't know about iscan and sane but libgphoto2 probably uses plugdev
because it's used very much in the same logic of mass storage removable
media.

--
Gilles Dartiguelongue <eva@gentoo.org>
Gentoo

Mailing List Archive

Attached Files:

Attached Files: