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