public inbox for linux-usb@vger.kernel.org
 help / color / mirror / Atom feed
From: Alan Stern <stern@rowland.harvard.edu>
To: Bastien Nocera <hadess@hadess.net>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-usb@vger.kernel.org,
	Benjamin Tissoires <benjamin.tissoires@redhat.com>,
	Peter Hutterer <peter.hutterer@who-t.net>
Subject: Re: [RFC v1] USB: core: add USBDEVFS_REVOKE ioctl
Date: Mon, 25 Apr 2022 12:14:17 -0400	[thread overview]
Message-ID: <YmbI2UB3HwAshj8Z@rowland.harvard.edu> (raw)
In-Reply-To: <1d82343a5987a308ac9bd3f6fd481bc12a608a24.camel@hadess.net>

On Mon, Apr 25, 2022 at 05:17:28PM +0200, Bastien Nocera wrote:
> evdev, HID and USB revoke are 3 separate implementations that are
> necessary for common device accesses to be revocable.
> 
> The HID patch shows how device access is implemented in systemd, with
> the seat leader (usually the compositor) being able to request fds from
> logind if the user doesn't already have access.
> 
> logind would then be responsible for closing the USB devices the user
> doesn't have access to anymore when logging out, or switching user. It
> could either close fds it passed out, or use BPF to revoke opened HID
> and USB devices without needing to act as an intermediary.
> 
> In short:
> - libusb programme opens USB device, either directly, or after asking
> the compositor to pass a fd (and being authorised to do so)
> - programme does its thing
> - fast user switch to another user
> - logind revokes libusb access for the old user
> - new user can use the device without problems

What happens if there's another fast user switch back to the original 
user?  Won't the original user then expect the old usbfs fds to continue 
working?

Doesn't the whole idea of revoking file access permissions go against 
the Unix philosophy of checking access rights only once, when a file is 
opened, but not thereafter?  I'm sure I've seen lots of emails by Linus 
complaining when people try to use a different approach.

Alan Stern

  parent reply	other threads:[~2022-04-25 16:14 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-25 13:23 [RFC v1] USB: core: add USBDEVFS_REVOKE ioctl Bastien Nocera
2022-04-25 13:28 ` Bastien Nocera
2022-04-25 13:49 ` Oliver Neukum
2022-04-25 14:25   ` Bastien Nocera
2022-04-25 14:45   ` Bastien Nocera
2022-04-25 14:10 ` Greg Kroah-Hartman
2022-04-25 14:28   ` Bastien Nocera
2022-04-25 15:00     ` Greg Kroah-Hartman
2022-04-25 15:17       ` Bastien Nocera
2022-04-25 15:45         ` Greg Kroah-Hartman
2022-04-26  2:27           ` Peter Hutterer
2022-04-26  7:14             ` Oliver Neukum
2022-04-26  7:21               ` Greg Kroah-Hartman
2022-04-26  8:46                 ` Oliver Neukum
2022-04-26 10:07                   ` Bastien Nocera
2022-04-26 10:30                     ` Greg Kroah-Hartman
2022-04-26 10:37                       ` Bastien Nocera
2022-04-26 11:10                         ` Greg Kroah-Hartman
2022-04-28 10:28                         ` Oliver Neukum
2022-04-28 11:21                           ` Bastien Nocera
2022-04-26 10:07             ` Bastien Nocera
2022-04-26 10:07           ` Bastien Nocera
2022-04-25 16:14         ` Alan Stern [this message]
2022-04-25 17:09           ` Benjamin Tissoires

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YmbI2UB3HwAshj8Z@rowland.harvard.edu \
    --to=stern@rowland.harvard.edu \
    --cc=benjamin.tissoires@redhat.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hadess@hadess.net \
    --cc=linux-usb@vger.kernel.org \
    --cc=peter.hutterer@who-t.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox