[pve-devel] Interest in a file manager interface within pve-manager?

[Dominik Csapak]

On 7/12/24 00:27, Blythe, Nathan F. - US via pve-devel wrote:
> 
> Hello,
> 

Hi, sorry for the late answer.

First thanks for a well written proposal/question. This is what we'd like to see if third-parties
are interested in making features/changes/etc.

I try to answer the question/proposal to the best of my knowledge, but maybe some of my colleagues
have additional things to say or want to correct me
(this could take a bit though, due to summer holiday season)

> We have a need for a non-network based (i.e. hypercall / out-of-band) file browser for containers and VMs within the pve-manager web UI. I'd like to be able to select a VM or container, click "More", and choose "File manager" and then browse the VM or container's file systems and upload or download files from my local system, through the web-browser.
> 
> For VMs (qemu), the qemu-guest-agent provides the ability to read/write guest files, and the pve API exposes it (with strict file size limits) as nodes->{node}->qemu->{vmid}->agent->file-*. Presumably, a web UI file manager would use that API endpoint, plus maybe an enhancement for directory listing and chunked upload/download (to support arbitrary size files).
> 
> For containers (LXC), the pct application can read/write files by (I think) mounting the container root file system on the host and touching it directly. But there's no corresponding API endpoint. If there were, it could be used by a future web UI file manager.
> 
> So to implement this feature, I think there are 5 steps:
> 
>    1.  Enhance the qemu-guest-agent and qm to support reading directory structure and creating directories.
>    2.  Enhance the pve API to expose these new features like file-read and file-write.
>    3.  Enhance the pve API to support chunked file read and write, for large files. Maybe also requiring an enhancement to the qemu-guest-agent?
>    4.  Enhance the pve API to support chunked file read/write, whole file read/write, and directory structure/creating directories (through direct filesystem interaction on the host).
>    5.  Write a JS front-end file manager, invokable from the Other menu, which uses these new/enhanced API endpoints to implement a general purpose out-of-band file manager.
> 
> Is there interest from the proxmox developers for something like this? If we started working on some of these items, would there be interest in accepting patches? Does my general approach look sound?

After a bit of internal discussion, the general tone is that we probably don't want to expose the
guest content/state by default this much now, but in the longer term it could be OK, but we see the
following issues:

* For now QEMU allows those guest calls by default, and there is at the moment not a really good
   way for configuring what's allowed and what not.
* Our privileges and ACLs are not really designed for this currently.
* Handling permissions (and other filesystem/guest "quirks") will be very hard
   (e.g. windows permissions are very different from linux/unix ones)

As breaking the host/guest barrier can have bad implications on security/data integrity/etc.
those problems would have to be solved before one could/should start with such a feature.

There is currently some work done on the QEMU side for limiting/configuring QGA calls:
https://lore.kernel.org/qemu-devel/20240604153242.251334-1-berrange@redhat.com/

When that's integrated, one could think about how our ACLs, privileges could be extended to allow
such things.

Only after those are solved, implementing this feature make sense.

What could be done in the meantime probably is to work with upstream QEMU to add
a directory listing to the qga and maybe some proper permission handling?

This is relatively independent from our side, since we don't actually ship
the guest agent ourselves, so this has to be solved upstream anyway.

So all in all, such a feature could work, but only in the longer term, this is nothing
for the short/midterm.

Hope this answers your questions. If not, just write again :)

> 
> (We also investigated using SPICE's folder-sharing capabilities and the spice-proxy provided by the host, but that doesn't work with the Windows virt-viewer client, only the Linux client. It looks like there was some interest in the past in enhancing xterm.js to support xmodem file transfer, but it didn't go far.)
> 
> Regards,
> Nathan Blythe
> CACI


Best regards
Dominik