On Mon, May 30, 2011 at 12:19:00PM -0400, Alan Stern wrote: > On Mon, 30 May 2011, Greg KH wrote: > > > On Mon, May 30, 2011 at 09:09:15AM +0200, Carl-Daniel Hailfinger wrote: > > > USB treats all devices attached to a wireless USB host controller as > > > unauthorized by default and all devices attached to a wired USB host > > > controller as authorized by default. This default setting can be changed > > > manually per host controller by setting authorized_default in sysfs, but > > > only after the host controller is already active. > > > AFAICS there is a race between userspace setting authorized_default on > > > startup and the USB subsystem enumerating devices on the USB bus. If a > > > USB device is already plugged into a wired USB host controller on > > > startup, it may be marked as authorized (and thus accessed by the > > > kernel/userspace) before userspace has a chance to set > > > authorized_default on that host controller. This is undesirable in kiosk > > > situations where the user may have access to the USB ports of a machine > > > during startup. > > > > > > Add an "authorized_default" parameter to the usbcore module which has > > > three settings: > > > 0 is not authorized for all devices > > > 1 is authorized for all devices > > > 2 is authorized for all devices except wireless (default, old behaviour) > > > > Ick, who is going to remember that "2" is the "default" here? > > > > I understand this could be a problem, but could you think up a cleaner > > interface for this? > > The parameter could become a boolean if case 1 is removed. After all, > 0 and 2 seem to be the most important cases. Yes, but 1 is something that some systems might want. > > Also, any new kernel/user API, like this one, needs to be documentented > > in Documentation/ABI/. > > Actually they should be mentioned in > Documentation/kernel-parameters.txt. Ah, good point, yes, that would work. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
