enable transfer of multiple files using wildcards

[PatrickTague]

from everything i can tell, the multipass transfer command is only useful for transferring single files/folders from a multipass instance to the host. for example, the command multipass transfer <instance>:dir/filename* . will give an SFTP error and actually create a file called * on the host (which itself seems very dangerous because it may prompt one to to want to run rm * instead of rm \*).

there is nothing in the documentation that says that wildcards are not supported, but that seems to be the case. honestly, i'm surprised that this is not supported, so if it is not, i would expect the documentation to be fairly clear about it. i see that there is a --recursive option, but that copies the parent directory and all of its contents, unlike what a wildcard would do.

[giuliazanchi]

Hi @PatrickTague , which version of Multipass are you running, and on which base system?

I have just tried replicating the issue on macOS with Multipass 1.15.0 and I can confirm that the * wildcard doesn't work, but instead of generating a file with the * character in it I get an error saying no matches found: instance:/my/path/filename*.

[PatrickTague]

I've verified the same behavior on the following:

• Linux Mint 22 (GNU/Linux 6.8.0-51-generic x86_64) with multipass 1.15.0
• Ubuntu 22.04.5 LTS (GNU/Linux 6.8.0-51-generic x86_64) with multipass 1.15.0

i should note that the wildcard doesn't work only in the case of transferring from the multipass instance to the host. it appears to work from host to instance. on both above systems, it created a file with the given wildcard pattern.

[ricab]

Hi @PatrickTague, the reason it works on the host-to-instance direction is that the glob pattern is actually expanded by your shell first. Multipass only ever gets the individual filename args in that case. You can verify this after set -x in your shell (use set +x to revert).

In the other direction, Multipass does not currently use a shell to expand the argument (as scp does, for instance). I agree it would be a nice addition, but in the meantime you can use mounts to achieve the same thing (or scp, after copying your key into authorized keys or setting a password on the ubuntu user.)

[giuliazanchi]

Thanks for your clarifications, @ricab !

Until this is fixed, like @PatrickTague suggested, it's a good idea to add a note to the documentation.

[PatrickTague]

@ricab your suggestion seems in some sense to violate desirable security properties of VMs, effectively creating pathways for breaking out of the VM barriers. from a security standpoint, your suggestion is undesirable. i would strongly suggest a host-driven approach that relies on the natural administrative powers of the vmm, rather than poking holes in barriers from the inside. as such, my original feature request stands.

[ricab]

@PatrickTague, as I said

I agree it would be a nice addition

I don't quite follow your meaning on security, but I only meant to offer alternatives to achieve what you want, if you want.