On Fri, Aug 05, 2022 at 02:38:16PM +0200, Bastien Nocera wrote: > On Thu, 2022-08-04 at 15:12 -0400, Alan Stern wrote: > > If you're going to revoke access to devices upon session switching, > > shouldn't the mechanism be more general? I mean, shouldn't it apply > > to > > all sorts of devices, not just those that happen to be USB? > > I don't see how that could be done in a generic way without causing > problems for devices accessed by multiple different parts of the OS. I don't know enough about the issues involved to help much. Still, doesn't it make more sense to offer logind a single API for revoking a session's access to all appropriate devices, rather than one API for revoking access to USB devices, another API for revoking access to HID devices, another API for revoking access to serial devices, another API for... etc.? This sounds a lot like the old BSD concept of "foreground" and "background" ttys. It didn't rely on revoking access to anything; maybe you should try to follow that example instead. Why would multiple different parts of the OS cause problems? > Revoking doesn't invalidate the file descriptor (whether in the > existing evdev revoke ioctl, or this USB function), and as you can see > in the patch, there are still things that can be done on the device > even when revoked. I didn't notice anything that can still be done. You might be able, for instance, to do an lseek on the device file descriptor, but that doesn't affect the device. > > Also, if you're going to use session switching as your criterion for > > revoking access to USB devices then what will you do to restore > > access > > when the session switches back? > > It's up to the application to do that. This is, for example, what > compositors do when accessing input devices which already have their > own revoke ioctl. Okay, I'll take your word for it. I'm not sure it's a good idea. > > > I have some notes and questions on the API as it is exposed. > > > > > > - I didn't see a point in having multiple kernel functions as entry > > > points as I was going to use a single BPF program as an entry > > > point, > > > which can check the arguments. Can I rely on the BPF program > > > checking > > > those arguments, or should I re-check them again in the kernel > > > implementation? > > > > What is there to check? > > Whether either busnum and devnum were passed, or a valid UID. Does it really matter if none of them are valid values? The call will end up doing nothing, but that's not really an error. For that matter, how do you define whether a UID is valid? As far as I know, the kernel doesn't keep track of valid UIDs; userspace does (in the /etc/passwd file or equivalent). > > For that matter, are you certain that basing this on the UID is the > > right > > way to go? What if there are two different login sessions both using > > the > > same UID? > > Do you know another identifier that's not kernel internal, or relying > on logind knowing the fd that we could use to differentiate those 2 > users? Process or session ID, perhaps? But I don't have a clear idea of how all this is meant to fit together. > Is there a use case for a USB device being opened, two separate > interfaces being claimed, by two different user sessions of the same > user? Well, you can ssh into the same machine from two different windows at the same time, and each of those ssh sessions could claim a different interface in the same USB device. (In theory, that is; but maybe you don't want to allow ssh sessions to access USB devices at all.) Alan Stern
