On Tue, Aug 09, 2022 at 03:27:16PM +0200, Bastien Nocera wrote: > On Tue, 2022-08-09 at 14:52 +0200, Greg Kroah-Hartman wrote: > > On Tue, Aug 09, 2022 at 01:18:43PM +0200, Bastien Nocera wrote: > > > > Revoke what exactly? > > > > > > Access. > > > > Access from what? > > revoke access to the USB device by one or all users. > > > > > You should be revoking the file descriptor that is > > > > open, not anything else as those are all transient and not > > > > uniquely > > > > identified and racy. > > > > > > They're "unique enough" (tm). The > > > > Are you sure? > > > > They are racy from what I can tell, especially as you have no locking > > in > > the patch that I noticed. > > It does. It's not good locking because I rewrote that API at least 4 > different times. > > > > How is this handling uid namespaces? > > > > > > The caller is supposed to be outside namespaces. It's a BPF > > > programme, > > > so must be loaded by a privileged caller. > > > > Where is "outside namespaces" defined anywhere? > > > > And how is this tied to any bpf program? I don't see that interface > > anywhere in this series, where did I miss that? > > It's in 2/2. > > The link to the user-space programme is in the "RFC v2" version of the > patch from last week. It calls into the kernel through that function > which is exported through BPF. > > > > > > > Again, just revoke the file descriptor, like the BSDs do for a > > > > tiny > > > > subset of device drivers. > > > > > > > > This comes up ever so often, why does someone not just add real > > > > revoke(2) support to Linux to handle it if they really really > > > > want it > > > > (I > > > > tried a long time ago, but didn't have it in me as I had no real > > > > users > > > > for it...) > > > > > > This was already explained twice, > > > > Explained where? > > https://www.spinics.net/lists/linux-usb/msg225448.html > https://www.spinics.net/lists/linux-usb/msg229753.html > > > > there's nothing to "hand out" those file descriptors, > > > > The kernel already handed out one when the device was opened using > > usbfs. > > > > > so no one but > > > the kernel and the programme itself > > > have that file descriptor, so it can't be used as an identifier. > > > > That's the only unique identifier that you want to revoke and "know" > > it > > is the device you are referring to. > > > > That's why I recommend creating revoke(2), not just an odd "pause the > > data to this device" api like this seems. That's just going to > > confuse > > lots of people as to "why did my device stop working?" > > "Why did my app stop working. Because you switched users and your app > needs to be updated to take that into account." > > I mean, ENODEV is returned on ioctls, it's just that the poll() doesn't > HUP. Bastien, maybe it would help if you explained to Greg and the mailing list exactly what you want to accomplish, both in more detail and from a higher-level viewpoint than you already have provided. Also, give an example or two showing when this mechanism would be invoked, how it would work, and what it would do. (Also, usbfs doesn't bind to USB devices but it does bind to USB interfaces; see claimintf() in devio.c.) Greg, unbinding usbfs would do only part of what Bastien wants. It would prevent a process from sending or receiving data over bulk, interrupt, or isochronous endpoints connected to interfaces that were already bound, but it would not prevent the process from accessing endpoint 0 or from re-binding to interfaces. What Bastien wants is a lot more like the kernel pretending to the process that the USB device has been disconnected and therefore is totally inaccessible. As for whether this is the best (or even the right) thing to do, or whether there are other ways to accomplish the ultimate goal of not allowing user programs to access certain local devices unless those programs belong to an active (console?) login session... That's beyond my scope. I'm also not clear on how namespaces figure into the whole discussion. Alan Stern
