From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1ISqTm-0007LP-KY for garchives@archives.gentoo.org; Wed, 05 Sep 2007 08:43:19 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.0/8.14.0) with SMTP id l858ZuCQ030092; Wed, 5 Sep 2007 08:35:56 GMT Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by robin.gentoo.org (8.14.0/8.14.0) with ESMTP id l858Y3sm027719 for ; Wed, 5 Sep 2007 08:34:03 GMT Received: by nf-out-0910.google.com with SMTP id 30so1717474nfu for ; Wed, 05 Sep 2007 01:34:03 -0700 (PDT) Received: by 10.78.159.7 with SMTP id h7mr4950982hue.1188981242258; Wed, 05 Sep 2007 01:34:02 -0700 (PDT) Received: by 10.78.23.17 with HTTP; Wed, 5 Sep 2007 01:34:02 -0700 (PDT) Message-ID: Date: Wed, 5 Sep 2007 01:34:02 -0700 From: "Alec Warner" Sender: antarus@scriptkitty.com To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [RFC] udev rules cleanup / merging rules files with other distros In-Reply-To: <20070905071049.GA22695@curie-int.orbis-terrarum.net> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200709041034.05788.zzam@gentoo.org> <20070905071049.GA22695@curie-int.orbis-terrarum.net> X-Google-Sender-Auth: 31498c245297920f X-Archives-Salt: dcdcc124-12ef-4dc7-b457-b37fd7a0024f X-Archives-Hash: 6e6ac3790c88024687dece24176e3e58 On 9/5/07, Robin H. Johnson 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