<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Hi Alex,</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
First of all, I and my whole team very much appreciate the time and effort you put into helping us with our use cases. We were all very impressed and astounded when reading your email replies as they all contained very careful thoughts. Everyone in our team
said you're such an amazing guy, we can see your passion in your work!</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
We're now more convinced that --device=all would be the best choice for us rather than trying to have a portal solution. We still have to solve the "hotplug" issue. We use the libusb on ubuntu to handle/detect hotplug event, but it's not working in our flatpak
build. Yes, the device shows up under /dev, but libusb couldn't detect it when it's plugged in after flatpak app has started. It sounds like from your explanation below it should be possible, so we would try to understand what's blocking libusb from working
in the sandbox. <br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Many thanks again!</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Regards,</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Winnie</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div>
<div id="appendonsend"></div>
<div style="font-family:Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"><b>From:</b> Alexander Larsson <alexl@redhat.com><br>
<b>Sent:</b> December 10, 2019 12:43 AM<br>
<b>To:</b> Winnie Poon <winniepoon_home@hotmail.com><br>
<b>Cc:</b> Flatpak List <flatpak@lists.freedesktop.org><br>
<b>Subject:</b> Re: possibility of contributing to portal support (USB mass storage)</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt">
<div class="PlainText">On Mon, Dec 9, 2019 at 8:29 PM Winnie Poon <winniepoon_home@hotmail.com> wrote:<br>
><br>
> Hi Alex,<br>
><br>
> Here's a short summary of our use case:<br>
><br>
> Our application is a remote access client (think: RDP or VNC). One feature is to remote raw USB devices. This allows devices to appear on the remote host as though they were directly plugging in. They would then be subject to whatever permissions, driver
support, etc, that is present on the remote host. As such, contrary to typical applications that would use USB devices at a high level (ie: reading files on a flash drive), our application isn't interested in the upper layer and is instead is just a dumb pipe
for the USB traffic of arbitrary devices.<br>
><br>
> We realize that raw access to arbitrary devices brings its own set of security concerns. Outside a sandbox we use capabilities(7) to gain access to the devices while minimizing the attack surface. From what we've learned thus far, it sounds as though using
the same design combined with --device=all is possibly the best choice at present.<br>
<br>
Yes, I think this is the only way for it to work right now. However,<br>
priority-increasing operations like setuid() and file capabilities<br>
don't work in the flatpak sandbox (or indeed *any* non-privileged<br>
linux user namespace) so depending on your design that may also run<br>
into issues. Something like system-set ACLs on the devices should work<br>
though.<br>
<br>
> Now the problem with --device=all, we found that USB device cannot be dynamically detected, so hotplug didn't work and we need that.<br>
<br>
How exactly did it fail? --device=all just means that the host /dev is<br>
visible as-is in the sandbox. Any new devices that appear in the<br>
should be visible to you. However, if you rely on udev to tell you<br>
about hotplug events that will not work. Unfortunately the current<br>
udev design depends on apps reading the system-wide udev database, and<br>
that is not ABI stable. I.e. you need to use the exact same libudev<br>
version as the one that wrote the db, which we can't guarantee in the<br>
container case. See here:<br>
<br>
<a href="https://lists.freedesktop.org/archives/systemd-devel/2014-October/024498.html">
https://lists.freedesktop.org/archives/systemd-devel/2014-October/024498.html</a><br>
<br>
That said, you *should* be able to see the devices show up in /dev and<br>
/sys, so you might be able to get hotplug events some other way. And<br>
if not, it might be possible to have some kind of portal or similar<br>
(ABI stable) service for such events.<br>
<br>
> So we were hoping switching to portal solution (we thought there was one) would avoid doing blanket device all access and also address the hotplug issue.<br>
<br>
So, how exactly would such a portal work? I imagine you would call it<br>
with an "open a usb device" request, it would show a dialog with all<br>
the devices on the host that the user has permissions to access, and<br>
then it would open the device and pass back the fd to the user.<br>
<br>
As long as this doesn't involve any increase in permissions inside the<br>
portal (which also runs as the user) then this is strictly safer than<br>
--device=all, and would work fine as a portal. However, if it involves<br>
the portal using setuid or file capabilities to get<br>
more-than-regular-user permissions then it sounds very scary.<br>
<br>
Also, is this really a useful API for you? It seems kind of limited by<br>
having to do the interaction from scratch each time you want to expose<br>
some device to the remote. I guess we could somehow remember user<br>
choices and let your app silently get access to that device later, but<br>
that seems a bit unsecure (how does the user know when the app has<br>
access? how do you revoke access?).<br>
<br>
Also, this depends on details of how the kernel USB device APIs work.<br>
Can we return a file descriptor that is guaranteed to only let you<br>
talk to a particular usb device? Also, can we forcefully revoke the<br>
access via the fd later somehow?<br>
<br>
</div>
</span></font></div>
</div>
</body>
</html>