I didn't really want MTP. Someone suggested it on IRC. What I really wanted is to be able to run my filters while using the normal QEMU USB driver. I'm not sure how MTP even works so I figured that before I learn anything about MTP I'll check here to see if I can implement this easily and contribute such a patch. On Wed, Apr 25, 2018, 11:20 PM Bandan Das <b...@redhat.com> wrote:
> Omer Katz <o...@kazuar-tech.com> writes: > > > What would be a simpler way to do this so that the guest machine would > > still be able to recognize the USB drive? > > Right now we're triggering a script whenever udev recognizes that a USB > > drive is plugged in. > > The script copies the allowed files to a certain folder. The guest has a > > cron job that periodically triggers scp from that folder to the guest. > > That's a very complicated flow and I just described only the flow which > > files are imported. I even omitted some of the moving parts since they > are > > irrelevant. > > Long story short our architecture is very complicated because of this > > issue. > > If you are using a physical USB drive, where do you envision the emulated > mtp share fits ? One way would be that your udev scripts only copies > files that can be read to the mtp share. Similarly, it only copies back > written files that accept a certain criteria from the share. > > Ofcourse, you can try out adding your filter hooks to dev-mtp.c as well > if you think that seems more suited to your use case. I was just > wondering whether reviewers will point it out as too specific. In the > worst case, it will be a in-house change that you will have to maintain > yourself. > > Bandan > > > > > On Wed, Apr 25, 2018, 7:17 PM Bandan Das <b...@redhat.com> wrote: > > > >> Omer Katz <o...@kazuar-tech.com> writes: > >> > >> > We're connecting USB drives that we want the guests to copy files > from. > >> > The user should only be allowed to copy certain files into the system. > >> > The same thing goes for copying files to the USB drive. We only allow > >> > certain files to be exported from the guest. > >> > >> If I understand your problem correctly, this should be doable by > plugging > >> in > >> your logic into usb_mtp_write_data for the write side and > >> usb_mtp_handle_data > >> for the read side. The write probably doesn't need a lot, you trigger an > >> error > >> response the moment your data has something you don't want and discard > the > >> new file. > >> For the read, though, you probably have to read the whole file first, > >> which is not what the current code is doing (I think). > >> > >> Apart from that dev-mtp.c is implementing a MTP server based on the MTP > >> spec and adding > >> something like this would be confusing, I also feel that this is too > >> specific a usecase > >> and as Daniel said, there are perhaps simpler ways of doing it. > >> > >> Bandan > >> > >> > On Wed, Apr 25, 2018, 12:57 PM Daniel P. Berrangé < > berra...@redhat.com> > >> > wrote: > >> > > >> >> On Mon, Apr 23, 2018 at 03:10:32PM +0000, Omer Katz wrote: > >> >> > Hi everyone, > >> >> > > >> >> > We have a use case that requires us to only allow certain files to > >> pass > >> >> > through to the guest machine from USB storage devices. > >> >> > > >> >> > I was told on IRC that such a feature does not exist but the > easiest > >> way > >> >> to > >> >> > achieve our goal is to contribute a patch the the MTP device driver > >> since > >> >> > other drivers operate on a filesystem level instead of a file level > >> which > >> >> > is what we need. > >> >> > >> >> IMHO the easiest way to stop the guest accessing files is to simply > not > >> >> put them in the directory that you are exporting the guest in the > first > >> >> place. If you have a directory that has some files you don't want > >> accessed > >> >> and can't remove them, then perhaps create a second directory and use > >> >> symlinks or hardlinks to pull in files from the original directory. > >> >> > >> >> > The plan is to pass the contents of each file to a program through > >> stdin > >> >> > and decide based on the exit code if the file should be allowed to > >> pass > >> >> > through to the guest or not. > >> >> > >> >> I can't say I like this idea. It is a really very inefficient and > heavy > >> >> solution. > >> >> > >> >> > Since this is the first time I'm contributing to QEMU I'd like some > >> >> > guidance to where the filtering code should be. > >> >> > https://github.com/qemu/qemu/blob/master/hw/usb/dev-mtp.c doesn't > >> look > >> >> that > >> >> > complicated but I still need to understand it better to continue. > >> >> > Furthermore, I need to know where to add such a command line > option to > >> >> > point QEMU to the filtering program. > >> >> > > >> >> > Would such a patch be accepted if all the requirements above are > met? > >> >> > >> >> Can you explain the usage scenario you have in more details, rather > than > >> >> just the high level abstract. > >> >> > >> >> > >> >> Regards, > >> >> Daniel > >> >> -- > >> >> |: https://berrange.com -o- > >> >> https://www.flickr.com/photos/dberrange :| > >> >> |: https://libvirt.org -o- > >> >> https://fstop138.berrange.com :| > >> >> |: https://entangle-photo.org -o- > >> >> https://www.instagram.com/dberrange :| > >> >> > >> >
