| 1 |
On Tue, Sep 04, 2007 at 10:34:05AM +0200, Matthias Schwarzott wrote: |
| 2 |
> So here we are: |
| 3 |
> In udev git-gtree suse and redhat rules are already merged. |
| 4 |
> But they use a different permission / group system than we have, they have |
| 5 |
> less groups and assign some desktop permissions via pam_console. |
| 6 |
Might want to talk to the Gentopia people, they were replacing the sucky |
| 7 |
pam_console with ConsoleKit, which is a partial solution - there are |
| 8 |
still Gentoo systems where neither pam_console nor ConsoleKit are |
| 9 |
wanted. |
| 10 |
|
| 11 |
> I also got all of our rules files (except 50-udev.rules) merged with what the |
| 12 |
> other distros use (already in git). |
| 13 |
> |
| 14 |
> Slackware has already started merging the rules with this "upstream" common |
| 15 |
> rules, and they also are more near to our approach by using groups for |
| 16 |
> audio/tape/cdrom/... |
| 17 |
> But I have not yet seen their rules yet. So for now we are on our own. |
| 18 |
> |
| 19 |
> So before doing to much work we should get a sane concept. |
| 20 |
> And for that concept we need: |
| 21 |
> * A (maybe formal) definition what each group should be used for |
| 22 |
> * what devices it contains (if not obvious) |
| 23 |
> * if permissions should be read/read-write for the group |
| 24 |
> * and nothing/read for world. |
| 25 |
> |
| 26 |
> The question arises as we use MODE=660 for most groups but upstream does 640 |
| 27 |
> most of the time. |
| 28 |
> |
| 29 |
> |
| 30 |
> This are the groups. |
| 31 |
> 1. audio |
| 32 |
> All alsa and oss devices. |
| 33 |
> Rules are not contained in upstream rules - they will in future be installed |
| 34 |
> by media-libs/alsa-lib |
| 35 |
> And upstream split of file for also also does not contain this group |
| 36 |
> but sure it should keep MODE=660 / group audio |
| 37 |
> (Or should we still support oss without having alsa installed) |
| 38 |
What is upstreams behavior with this? Will their alsa-lib install |
| 39 |
something similar? I'm not up on ALSA stuff, does being in the audio |
| 40 |
group mean I can play music? |
| 41 |
|
| 42 |
> 2. cdrom |
| 43 |
> Used for all cdrom/cdwriter devices and for scsi also the associated sg |
| 44 |
> device. |
| 45 |
> MODE=660 |
| 46 |
> Upstream has no such group - member of disk for them. |
| 47 |
How does upstream deal with expecting users to use burners? |
| 48 |
Plain CDROM mounting doesn't need the cdrom group, as /bin/mount is |
| 49 |
setuid, however special operations on CDs (like readcd/readom) should |
| 50 |
also be allowed to some users? |
| 51 |
|
| 52 |
> 3. cdrw |
| 53 |
> Only used for pktcdvd with MODE=660 |
| 54 |
> Should this be merged into group cdrom? |
| 55 |
I think merge. |
| 56 |
|
| 57 |
> 4. disk |
| 58 |
> Contains every device with SUBSYSTEM==block, with MODE=660 |
| 59 |
> the raw-devices (still needed?) |
| 60 |
> + some devices needed for ata-over-ethernet (with modes 220 or 440) |
| 61 |
> Upstream uses MODE=640 (Like old unix group for backup usage). |
| 62 |
The 'dump' backup case is the only one I'm aware of that's valid (and it |
| 63 |
can use 640). |
| 64 |
Why does ATAoE need user-level access? The 220/440 modes seem weird to |
| 65 |
me. |
| 66 |
|
| 67 |
> 5. floppy |
| 68 |
> The fd* devices, MODE=660 |
| 69 |
> Upstream uses MODE=640 |
| 70 |
Same field as cdrom group. |
| 71 |
|
| 72 |
> 6. lp |
| 73 |
> Used for all *lp* and parport devices with MODE=660 |
| 74 |
> Upstream uses it same way. |
| 75 |
Might be a place for scanner usage, but CUPs for modern printing runs as |
| 76 |
a daemon, users should not need the lp access. |
| 77 |
|
| 78 |
> 7. tape |
| 79 |
> Contains all tape devices with MODE=660. |
| 80 |
> Upstream has no such group - member of disk group. |
| 81 |
You know my standpoint on tape. It's a critical group for app-backup. |
| 82 |
I've actually got one further addition to it since we spoke yesterday, |
| 83 |
making the relevant sg devices owned by the tape group. |
| 84 |
That said, the backup usage of tape could be merged with disk - given |
| 85 |
that backup may use both of them, and backup apps tend to run with a lot |
| 86 |
of powers anyway (either as root for global FS access, or with the disk |
| 87 |
group for running 'dump'). |
| 88 |
|
| 89 |
> 8. tty |
| 90 |
> Same usage as upstream (maybe only very slight changes) |
| 91 |
I don't know. |
| 92 |
|
| 93 |
> |
| 94 |
> 9. usb |
| 95 |
> Devices for libusb (/dev/bus/usb/...) with MODE=664. |
| 96 |
> + legousbtower device |
| 97 |
> Upstream has no such group but has libusb stuff root:root with MODE=644 |
| 98 |
Look at the additional rules installed by NUT (70-nut-usbups.rules). |
| 99 |
They all have the form of: |
| 100 |
SYSFS{idVendor}=="0463", SYSFS{idProduct}=="ffff", MODE="664", GROUP="nut" |
| 101 |
Thus the USB stuff should have a sane default, and then become more |
| 102 |
empowered by custom udev rules per application. |
| 103 |
|
| 104 |
> 10. uucp |
| 105 |
> serial devices, isdn and more for dialout usage MODE=660 |
| 106 |
> Upstream uses it same way. |
| 107 |
I don't know. |
| 108 |
|
| 109 |
> 11. video |
| 110 |
> A lot of misc stuff: dri/card*, nvidia, 3dfx, framebuffer, ieee1394, v4l, dvb |
| 111 |
> with MODE=660 |
| 112 |
> Upstream has no such group - they keep group at root and grant access via pam. |
| 113 |
I don't know. |
| 114 |
|
| 115 |
> Groups we do not use yet: |
| 116 |
> 12. kmem |
| 117 |
> Upstream uses it for /dev/mem /dev/kmem /dev/port with MODE=640 |
| 118 |
> Should be ok to use - we have group=root, MODE=640 for now |
| 119 |
Should be sane to add, iirc it's needed for kexec right? |
| 120 |
|
| 121 |
-- |
| 122 |
Robin Hugh Johnson |
| 123 |
Gentoo Linux Developer & Infra Guy |
| 124 |
E-Mail : robbat2@g.o |
| 125 |
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 |
Archives