From: Oliver Neukum <oliver@neukum.name>
To: linux-hotplug@vger.kernel.org
Subject: hotplug and granting permissions
Date: Sat, 12 Oct 2002 07:49:36 +0000 [thread overview]
Message-ID: <marc-linux-hotplug-103440928513314@msgid-missing> (raw)
Am Samstag, 12. Oktober 2002 07:55 schrieb Greg KH:
> On Sat, Oct 12, 2002 at 12:21:29AM +0200, Oliver Neukum wrote:
> > Am Freitag, 11. Oktober 2002 23:43 schrieb Alan Cox:
> > > On Fri, 2002-10-11 at 21:30, Oliver Neukum wrote:
> > > > That is not true. Hotplugging changes it. By assigning new devices
> > > > to existing device nodes, the kernel _does_ hand out permissions.
> > >
> > > Only if you got the design wrong. The kernel should pass hotplug the
> > > info to create the device nodes.
> >
> > Then you need a very large number of device numbers.
>
> What? No you don't. But who cares, I'll get random device number
> generation into the kernel eventually...
This won't help. You need a counter. As Alan has pointed out to us
lesser mortals, the problem is reuse. Therefore you need several times
the maximum number of devices on a bus to make this scheme work.
Under these circumstances (20 bit minors) it's indeed the easiest solution.
IMHO quick and dirty, but this is a matter of personal taste.
If you use random generation you'd have to keep a record of previously
used numbers.
> And this is off topic for this thread :)
Yes. And for this list. Therefore I changed topic and list.
> > > If you are dealing with a device where a node might be reused, yes you
> > > might want to store a generation count and return -EIO if the handle
> > > has a mismatched generation count.
> >
> > That you can only do if you have a handle. In which case the problem
> > is easy. But open() takes only a name. You cannot sanely put a generation
> > count into that.
> > IMHO if you reuse device nodes, you have to reset permissions on them
> > in kernel space.
>
> Nope, not going to happen. But I'll save this discussion for later,
> whenever we get enough code into the kernel to be worrying about this.
We have code in the kernel that causes this. And it's bad to add stuff before
we know how to make it work properly.
Regards
Oliver
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
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
reply other threads:[~2002-10-12 7:49 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=marc-linux-hotplug-103440928513314@msgid-missing \
--to=oliver@neukum.name \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).