podman image scp should support local Unix sockets

[vlk-charles]

Feature request description

podman image scp accepts connections added with podman system connection add. It should not "choke" on some of these connections. A connection can be specified as a local Unix socket file (according to the manual page):

podman system connection add otheruser unix:///run/user/1001/podman/podman.sock

However, the following command "chokes" on it:

$ podman image scp otheruser::someimage
Error: failed to connect: dial tcp: lookup unix:: no such host

Suggest potential solution

As Unix sockets over SSH seem to be supported (according to one of the examples in the manual page), I would expect local ones to be supported as well.

Have you considered any alternatives?

I also tried the option mentioned in the manual page as:

Images can also be transferred from rootful to rootless storage on the same machine without using sshd.

But that complained about missing machinectl. I know that can probably be made to work but I tired avoiding machinectl.

I guess it is possible to get SSH to work for localhost but that seems superfluous.

Additional context

Client:       Podman Engine
Version:      4.9.4-rhel
API Version:  4.9.4-rhel
Go Version:   go1.21.11 (Red Hat 1.21.11-1.el9_4)
Built:        Mon Jul  8 16:30:30 2024
OS/Arch:      linux/amd64

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[vlk-charles]

Is no-one interested in this?

[rhatdan]

Are you interested in opening a PR?

[zackattackz]

I'd be interested if @vlk-charles is not

[rhatdan]

You got it.

[zackattackz]

Ok so having looked into it a little bit, I'll need some feedback on a proposal for an extension to the command's syntax:

For instance, we could do something like @vlk-charles suggests: podman image scp unix:///path/to/sending.socket::alpine.

There are many cases to consider though in the same vein, such as sending/receiving from different users, while specifying the sockets to use on the sending and receiving ends.

To give other examples:

root with special socket -> our user with default socket:

podman image scp root@unix:///path/to/sending.socket::alpine 

same as above but with named connection via podman system connection add:

podman system connection add sender unix:///path/to/sending.socket
podman image scp root@sender::alpine

our user with default socket -> root with special socket:

podman image scp alpine root@unix:///path/to/receiving.socket::

same as above but with named connection:

podman system connection add receiver unix:///path/to/receiving.socket
podman image scp alpine root@receiver::

root with default socket -> our user with special socket (note that "localhost" would just act as the user's default socket location):

podman image scp root@localhost::alpine unix:///path/to/receiving.socket::

same as above but root -> another user:

podman image scp root@localhost::alpine username@unix:///path/to/receiving.socket::

our user -> our user but with different sockets:

podman image scp unix:///path/to/sending.socket::alpine unix:///path/to/receiving.socket::

same as above but with named connections via podman system connection add:

podman system connection add sender unix:///path/to/sending.socket
podman system connection add receiver unix:///path/to/receiving.socket
podman image scp sender::alpine receiver::

This kind of syntax could also be extended to remote->local transfers to specify users and local socket to use, for example:

podman image scp [email protected]:22::alpine root@unix:///some_socket.sock::

^ Though I may be getting ahead of myself here, I think a more unified syntax would be nice for cases like this.

This would be in line with the syntax that already exists for local->local transfers, it uses, and it also shares the syntax for specifying the path to the socket that remote->local transfers use. The goal would be to extend the current syntax in a backwards-compatible way.

The only thing I'm a little tripped up on is how to integrate something like this example from the man page:

Copy specified image from local storage to remote connection:
podman image scp alpine Fedora::/home/charliedoern/Documents/alpine

Would this also mean you should be able to do this (which you can't do currently btw):

podman image scp alpine root@localhost::/root/Documents/alpine

To be able copy the image from local to /root/Documents/alpine? How could the socket play into this, if at all? (Just ignore the socket if provided, bc we're just writing to a file? I'm not positive how the original example would work anyways)

Ignoring that point above, the overall proposed syntax's SYNOPSIS would be:

podman image scp [OPTIONS] [[USER@]URI::]NAME[:TAG] [[USER@]URI::]

Anyways, sorry this is so drawn out. But I believe this syntax extension could be a nice addition to make usage of local transfers and remote transfers more similar. To me, it seems necessary to do all this in order to implement the feature as requested, at least while also working with situations like the examples I provided. I am open to feedback and criticism, as I am sure I've missed some considerations.

[vlk-charles]

Thank you for picking this up, @zackattackz.

Is it necessary to specify a user when referring to a Unix socket? Such a socket is already associated with a specific instance of the Podman daemon running under a certain user. Or am I mistaken?

[zackattackz]

@vlk-charles

You mean like how you'd know the user ID is X based on it being at path /run/user/X/podman/podman.sock ?

It's true, but those are just defaults, and there's nothing stopping you from making a socket file at any location at all. So I figured you'd still need to specify the user.

This is how the --url parameter works already with SSH schema. It defaults to the normal socket files, but you can specify with a path the one you want to use, as well as the user.

So I was thinking podman image scp should align with that parameter more closely.

EDIT:
In the case of local scp, I'd think you'd still need to specify the user anyways for the same reason that the sockets could exist anywhere.