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 <gentoo-dev+bounces-26113-garchives=archives.gentoo.org@gentoo.org>)
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 <gentoo-dev@lists.gentoo.org>; Wed, 5 Sep 2007 08:34:03 GMT
Received: by nf-out-0910.google.com with SMTP id 30so1717474nfu
for <gentoo-dev@lists.gentoo.org>; 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: <b41005390709050134g2ebf02a8t570a6aa4035faebd@mail.gmail.com>
Date: Wed, 5 Sep 2007 01:34:02 -0700
From: "Alec Warner" <antarus@gentoo.org>
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: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
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 <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