From: Hyriand <hyriand@thegraveyard.org>
To: linux-hotplug@vger.kernel.org
Subject: Re: udev-021 rule based permissions (+patch)
Date: Thu, 04 Mar 2004 11:37:06 +0000 [thread overview]
Message-ID: <200403041237.06122.hyriand@thegraveyard.org> (raw)
In-Reply-To: <200403031634.43358.hyriand@thegraveyard.org>
On Wednesday 03 March 2004 19:41, you wrote:
> On Wed, Mar 03, 2004 at 04:34:43PM +0100, Hyriand wrote:
> > On Wednesday 03 March 2004 16:10, you wrote:
> > > On Wed, Mar 03, 2004 at 03:15:45PM +0100, Hyriand wrote:
> > > > Dear Greg,
> > > >
> > > > First of all, thanks for your excellent work on udev (and related
> > > > tools), I really enjoyed giving devfs a big kick and wiping every
> > > > trace of it from my kernel.
> > >
> > > Thanks for your kind words.
> > >
> > > > But now for the direct cause of this e-mail, rule-based permissions.
> > > > Quite simple actually, it adds OWNER, GROUP and MODE fields to the
> > > > device rules, and applies those if no applicable rule is found in the
> > > > permissions table. I know this might be against conventions, but it
> > > > adds some flexibility since you can't change permissions based on a
> > > > symlink name.
> > >
> > > Hm, I don't understand. What is wrong with the current scheme of using
> > > the udev.permissions file for this?
> >
> > An over-simplified case would be a laptop that has a slot in which you
> > can insert a cd-recorder or a dvd-rom drive. If the cd-rw is inserted,
> > the group of the "hdc" device should be "cdrw" (well, depends on how you
> > arrange security of course), and if the dvd-rom drive is inserted, the
> > group should be something else. There's currently one way of achieving
> > that, making the device name change (cdrom or dvdrom), settings up
> > permissions for that and symlinking it to %k (for compatibility reasons),
> > but I thought this was a slightly cleaner way (configuration wise) of
> > setting up different permissions for a device without having to symlink
> > it.
> >
> > Or in other words, "hdc" (or whatever other device file) might not always
> > refer to the same device, and should have different permissions
> > accordingly.
>
> Then provide a different name for the device, which allows you to have
> different permissions. That's the simplest solution for this, correct?
>
> thanks,
>
> greg k-h
Sure, that's a possibility (and creating a symlink to not confuse applications
that work on both the cdrw and the dvd drive, like mount), but, this adds a
symlink which clutters /dev.. But I guess I'll just have to live with that :)
Hyriand
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
prev parent reply other threads:[~2004-03-04 11:37 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-03 15:34 udev-021 rule based permissions (+patch) Hyriand
2004-03-03 18:41 ` Greg KH
2004-03-04 11:37 ` Hyriand [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200403041237.06122.hyriand@thegraveyard.org \
--to=hyriand@thegraveyard.org \
--cc=linux-hotplug@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.