From: Bandan Das <bsd@redhat.com>
To: Omer Katz <omer@kazuar-tech.com>
Cc: "Daniel P. Berrangé" <berrange@redhat.com>,
"Gerd Hoffmann" <kraxel@redhat.com>,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Filtering files passing through MTP devices
Date: Wed, 25 Apr 2018 16:20:01 -0400 [thread overview]
Message-ID: <jpgbme7f37y.fsf@linux.bootlegged.copy> (raw)
In-Reply-To: <CAA-pg_rGtB_XVQ1+zWq3W7=SVMXJxoEOu9C7573pMNAA2yUb1g@mail.gmail.com> (Omer Katz's message of "Wed, 25 Apr 2018 18:05:50 +0000")
Omer Katz <omer@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 <bsd@redhat.com> wrote:
>
>> Omer Katz <omer@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é <berrange@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 :|
>> >>
>>
next prev parent reply other threads:[~2018-04-25 20:20 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-23 15:10 [Qemu-devel] Filtering files passing through MTP devices Omer Katz
2018-04-25 9:56 ` Daniel P. Berrangé
2018-04-25 10:39 ` Omer Katz
2018-04-25 16:17 ` Bandan Das
2018-04-25 18:05 ` Omer Katz
2018-04-25 20:20 ` Bandan Das [this message]
2018-04-25 20:46 ` Omer Katz
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=jpgbme7f37y.fsf@linux.bootlegged.copy \
--to=bsd@redhat.com \
--cc=berrange@redhat.com \
--cc=kraxel@redhat.com \
--cc=omer@kazuar-tech.com \
--cc=qemu-devel@nongnu.org \
/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;
as well as URLs for NNTP newsgroup(s).