Re: [RFC v1] USB: core: add USBDEVFS_REVOKE ioctl

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Tue, Apr 26, 2022 at 12:37:14PM +0200, Bastien Nocera wrote:
> On Tue, 2022-04-26 at 12:30 +0200, Greg Kroah-Hartman wrote:
> > On Tue, Apr 26, 2022 at 12:07:32PM +0200, Bastien Nocera wrote:
> > > On Tue, 2022-04-26 at 10:46 +0200, Oliver Neukum wrote:
> > > > 
> > > > 
> > > > On 26.04.22 09:21, Greg Kroah-Hartman wrote:
> > > > > Yes, but, it's not so simple.  Many people have asked for
> > > > > revoke()
> > > > > to be
> > > > > added as a syscall like is in the BSDs, but the BSDs only allow
> > > > > that for
> > > > > a very small subset of file descriptor types, and doing it in a
> > > > > generic
> > > > > fashion seems very difficult (I tried a few years ago and gave
> > > > > up,
> > > > > but
> > > > > my knowledge of the vfs layer is minimal.)
> > > > Well, then we should go for the minimalist approach and just
> > > > add a hook to VFS. Multiple different ioctl()s are definitely a
> > > > bad
> > > > idea.
> > > > An frevoke() looks much easier to do than one based on paths.
> > > > If I understand the issue behind the proposal correctly the
> > > > caller
> > > > has opened the device.
> > > 
> > > Doesn't look like FreeBSD at least has an frevoke() syscall
> > > anymore, it
> > > had an FREVOKE flag, which is now a define for the O_VERIFY option
> > > which has quite different semantics:
> > > https://www.freebsd.org/cgi/man.cgi?sektion=2&query=open
> > 
> > Take a look at this implementation:
> >         https://man.openbsd.org/revoke.2
> > 
> I don't think anyone wants to implement path based syscalls, and again,
> it's equivalent to remote closing the fd, not to disabling the access
> to the device:
> "If the file is a special file for a device which is open, the device
> close function is called as if all open references to the file had been
> closed."

You forgot the sentence before that which is the functionality we want
here:
	Subsequent operations on any such descriptors fail, with the
	exceptions that a read() from a tty which has been revoked
	returns a count of zero (end of file), and a close() call will
	succeed.

And don't do it only for a tty device, but for any device that
implements it.

And yes, we don't want to work off of a path, but a file descriptor:
	int revoke(int fd);

> If there's an implementation done at the VFS level, it should probably
> try to steer away from those earlier disparate implementations.

Agreed.

thanks,

greg k-h