Re: [RFC v2 1/2] USB: core: add a way to revoke access to open USB devices

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 2022-08-05 at 10:42 -0400, Alan Stern wrote:
> > On Fri, Aug 05, 2022 at 02:38:13PM +0200, Bastien Nocera wrote:
> > > > On Thu, 2022-08-04 at 15:25 -0400, Alan Stern wrote:
> > > > > > Have you considered what should happen if two processes
> > > > > > share the
> > > > > > same 
> > > > > > file descriptor (and hence the same usb_dev_state
> > > > > > structure) and > > > you
> > > > > > want 
> > > > > > to revoke access for one of the processes but not the
> > > > > > other?
> > > > 
> > > > No, because this isn't something that happens in practice, as
> > > > it's
> > > > simpler for each programme to open their own file descriptor
> > > > and > > claim
> > > > the interfaces they need on their own.
> > 
> > But it is possible for a program to open a USB device and then fork
> > several children.  The children would all share the same file >
> > descriptor.
> > 
> > I have no idea how often this happens in practice.  But kernel
> > design > is 
> > supposed to be based on correctness, not on handling only things
> > that
> > crop up "in practice".

Given that the API makes no such promises, I think we're fine. The end
goal is "user can't use device" or possibly "user in namespace can't
use device" to cut sandboxes off from their USB devices.

We don't need surgical precision revocation, but I would be happy to
implement this API if we can come up with a good way to target specific
programs.

> > > > > > I have the feeling that this part of the function (matching
> > > > > > the
> > > > > > busnum 
> > > > > > and devnum values) doesn't belong here but rather with the
> > > > > > > > > iteration 
> > > > > > routines in your 2/2 patch.  Filtering of devices generally
> > > > > > is > > > done
> > > > > > as 
> > > > > > part of the iteration.  As an added bonus, doing it that
> > > > > > way > > > means
> > > > > > you 
> > > > > > don't need to pass around pointers to usb_revoke_match > >
> > > > > > > structures.
> > > > 
> > > > I felt it better to have the filtering done in one place, to
> > > > avoid
> > > > passing just a uid to check to that function.
> > 
> > There's nothing wrong with passing just a uid.  Especially since
> > the > same 
> > device might be open multiple times, for varying uids.
> > 
> > > > Should I rename the function something like
> > > > usb_revoke_for_uid() ?
> > 
> > Up to you.

I've done that now.



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux