Thomas Sailer wrote:
>
> David Brownell wrote:
>
> > In any case, it doesn't sound like the stuff you mentioned building
> > on top of it could address the basic problem: "read" mode permissions
> > only seems to give permission to access a cached device descriptor.
> > None of the other standard read-only device operations can be done.
>
> All actions that lead to a transaction on the USB bus require
> write access, on purpose. Otherwise, given buggy devices
> (which exist), any user could kill that device,
> and if it was eg. a block device, bad things would happen.
Requiring write access isn't sufficient, in the case of
multiple writers.
And it should never be necessary, in the case of standard
device operations GET operations that aren't interrupting
some other device activity (e.g. in the middle of some
composite message exchange).
Are you saying that certain devices are buggy enough
that only very specialized drivers, knowing their quirks,
can even issue GET_STATUS (as above)? If so, then maybe
the answer is to support a "single accessor" model for
drivers, rather than only the model that's there now.
For example, while I don't think it's appropriate to let
user programs try raw disk IO via USB (there are better
APIs for that), I do expect to be able to write user mode
code that works with power management policies, and so
must be able to talk to hubs ... without clobbering what
the kernel hub driver may be doing.
So I think it's likely that some synchronization mechanism
is missing here, and
> > That problem is easy enough to patch, though one needs to be careful
> > of course. I can start on it next week.
>
> Please don't.
>
> The idea is to have a user space daemon which selectively
> (and configurably by the user) adjusts permissions.
>
> This is policy and IMO belongs into userspace.
Setting permissions, OK -- but my observation is that
the current "read" permission doesn't match what "read"
permission normally matches.
Given what you said above, I think you're trying to use
access control mechanisms to achieve something that's
not really an access control problem.
> > Did you choose an approach for libusb yet? Do they really both work?
>
> Yes, at least with usbstress, usb.in.tum.de
I'll have to take a look at it.
- Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
