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

[Dominik Csapak]

sorry for the noise, it seems i forgot to put you in CC, so now again with that...

On 8/13/24 10:35, Dominik Csapak wrote:
> 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
> 
> 
> _______________________________________________
> pve-devel mailing list
> pve-devel at lists.proxmox.com
> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
> 
>