Re: [PATCH v2 00/20] block/export: Allow exporting BDSs via FUSE

[Max Reitz <mreitz@redhat.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3761 bytes --]

On 22.09.20 17:58, Daniel P. Berrangé wrote:
> On Tue, Sep 22, 2020 at 12:49:12PM +0200, Max Reitz wrote:
>> Based-on: <20200907182011.521007-1-kwolf@redhat.com>
>>           (“block/export: Add infrastructure and QAPI for block exports”)
>>
>> (Though its patch 16 needs a s/= \&blk_exp_nbd/= drv/ on top.)
>>
>> v1: https://lists.nongnu.org/archive/html/qemu-block/2019-12/msg00451.html
>>
>> Branch: https://github.com/XanClic/qemu.git fuse-exports-v2
>> Branch: https://git.xanclic.moe/XanClic/qemu.git fuse-exports-v2
>>
>>
>> Hi,
>>
>> Ever since I found out that you can mount FUSE filesystems on regular
>> files (not just directories), I had the idea of adding FUSE block
>> exports to qemu where you can export block nodes as raw images.  The
>> best thing is that you’d be able to mount an image on itself, so
>> whatever format it may be in, qemu lets it appear as a raw image (and
>> you can then use regular tools like dd on it).
>>
>> The performance is quite bad so far, but we can always try to improve it
>> if the need arises.  For now I consider it mostly a cute feature to get
>> easy access to the raw contents of image files in any format (without
>> requiring root rights).
> 
> Aside from the iotests, so you forsee any particular use cases
> where this feature is desirable / important ?

No.

I implemented this feature for fun last year (when I realized that FUSE
allows regular files to be mount points), and I got positive reactions.
 I assumed others would find it as nice as me to be able to quickly
access an image file without requiring root rights (and then device file
accesses), or setting up an NBD chain.

(Though it should be noted that when I first came up with the feature,
nbdfuse did not exist yet.)

(It should also be noted that my original idea was to have a new
executable qemu-blkfuse that would basically allow you to invoke
“qemu-blkfuse $img”, and then $img would appear as a raw image.  To me,
that appeared very useful because it was so simple.  I admit that the
current proposal, which relies on the storage-daemon, has none of that
simplicity.  But if that’s the problem that prevents this from being
considered useful, I’m sure we (I) can figure something out.  Perhaps a
simple script, bundled with qemu, that can generate -blockdev
invocations based on the result of file(1).)

> Looking at it from a security POV, I'm not thrilled about the
> idea of granting QEMU permission to use the mount syscall for
> seccomp or SELinux. IOW, I expect this feature won't be something
> we want to expose in QEMU guests managed by libvirt, which would
> limit how widely it can be used.

I don’t expect this to be used through QEMU very much, but through the
storage daemon.  I assume that for the storage daemon, the permissions
can effectively be fine-tuned for each export, because you can “just”
launch another instance.

> QEMU can export NBD. Would it make sense to do this as an NBD
> client ? There's already https://libguestfs.org/nbdfuse.1.html
> but IIUC that exposes it as a file within a dir. Presumably
> it is not too hard to make it support exposing it directly as
> a file too.

I don’t like that idea very much, because my main gripe with the current
state of my proposal is that it’s more cumbersome than
“qemu-blkfuse $img”.  Adding more indirections won’t make it simpler.

> I wonder how performance compares between your native FUSE
> impl in QEMU vs NBD FUSE ?

Last year, I tried various ways of improving performance and nothing
really amounted to much.  So in the end I settled for a simple and naive
implementation, for it to be improved in case anyone cares for it.

Max


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]