On Thu, Apr 13, 2000, Horst von Brand <vonbrand@sleipnir.valparaiso.cl> wrote:
> Johannes Erdfelt <jerdfelt@sventech.com> said:
>
> > Actually, this won't work wiht PNP devices, like USB. We want the
> > permissions to follow the device, not whatever device node it was
> > assigned this particular time.
>
> How do you propose to keep track of the devices? Firstly, if there are two
> identical mice, I'd distinguish them as the "left" and "right" ones, not by
> their serial numbers. Further, you'd need to record each device that was
> someday (however briefly) connected to the system, and this "memory" would
> have to be non-volatile, and must be easy to edit (printer is busted, gets
> replaced by a new one should not create a new printer from scratch). Sounds
> awful. Besides, it solves only part of the problem: I don't want to know
> about zip drives 1, 2, 3 and 4; in the end I want to keep track of the data
> on the zip _disks_.
>
> The age-old mind-body duality: You want to keep the "real world" out of the
> kernel, and at the same time you need the kernel to be aware in detail of
> what is going on out there.
>
> The only real way out is to redefine the problem, as I can't see any way to
> solve the given one.
It is solvable, in user space.
Take a look at the discussion I had with Alan Cox, David Elliott and
Richard Gooch today about naming and you can track devices a couple of
different ways.
It's not perfect. However, it does solve the problem for the devices
that can be solved.
But, the idea is that devfsd (or some other daemon) knows the device and
sets permissions appropriately. It then saves it to a database and it
follows the device, based on serial number, bus topology and/or
vendor/product/revision.
Unfortunately, it won't be solvable for all devices in all
circumstances, but it's the best possible solution.
JE
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Apr 15 2000 - 21:00:23 EST