On Fri, May 8, 2009 at 16:06, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Fri, 8 May 2009, Kay Sievers wrote: > >> You mentioned earlier, that you would need to match the holder of the >> "lock" and the one that accesses the device? > > Yes. That is, a process shouldn't be allowed to access a locked device > unless that process is the lock holder. You think the pid or the uid would make more sense? >> Wouldn't it be sufficient already, if you can take a "lock" at the >> specific port, that prevents the kernel to access the device when it >> shows up? > > I don't know how the people requesting this feature would feel about > that. They seem to want to lock out other processes as well as locking > out the kernel. Might be useful, yeah. I could think of use cases where a specific uid wants to lock a device, by holding the lock file open, and only the same uid (could be a different pid) can claim the device from userspace. >> You thought of supporting a number of different users, with different >> uids, or would that be a root-only action? > > A typical use case would be somebody running an emulator like QEMU. In > theory there could be multiple QEMU processes running concurrently, > each owning a different set of ports. The uids might be different or > they might all be the same. > > Setting the lock permissions would be up to userspace. Yeah, sounds fine. Kay -- 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
