podman-remote run --cidfile results in files deleted on container host

[allisonkarlitskaya]

Issue Description

podman-remote has some understandable restrictions with respect to handling of --cidfile. In particular, we can't expect that the cidfile gets properly cleaned up on container exit in all cases, since there's nothing around to delete it.

Unfortunately, podman running on the container host will delete an different file (with the same name), if it is present.

Consider a typical toolbox setup where /var/tmp is different inside and outside of the toolbox. If you do podman-remote run --cidfile /var/tmp/cidfile inside of the toolbox then podman will erase /var/tmp/cidfile on the host system when the container exits.

I think this is probably because the path of the cidfile gets transmitted from podman-remote to podman on the container host, where podman accidentally interprets it as a local path. Transmitting the filename in the first place is never appropriate since this filename is meaningless on the container host, and the container host should also ensure that it rejects the filename (if it is transmitted) for the same reason.

Steps to reproduce the issue

Here's a small example session that reproduces the issue. I have two terminal windows open and go between running commands on the host and inside of the toolbox. The order of things shown here is the chronological order in which the commands were run.

Again: key to this example is that /var/tmp is different on the host and in the toolbox.

Create a file that's only visible on the host:

host$ echo 'IMPORTANT DATA' > /var/tmp/cidfile
host$ cat /var/tmp/cidfile
IMPORTANT DATA

This file is not visible inside of toolbox.

toolbox$ cat /var/tmp/cidfile
cat: /var/tmp/cidfile: No such file or directory

Then in the toolbox we start a container with a cidfile on the same name, but this is a different file, since /var/tmp is different:

toolbox$ podman-remote run --cidfile /var/tmp/cidfile fedora:latest true
toolbox$ cat /var/tmp/cidfile
2f8b3066a42d74b3278b732b336b4e7c9993c74d411a1d2f24a5badb8ecc1d92

Of course, on the host, our file is still present, in its original form.

host$ cat /var/tmp/cidfile
IMPORTANT DATA

Back in the toolbox, time to get rid of our container. We're not surprised that the cidfile doesn't get erased, since this is podman-remote:

toolbox$ podman-remote rm --cidfile /var/tmp/cidfile
2f8b3066a42d74b3278b732b336b4e7c9993c74d411a1d2f24a5badb8ecc1d92
toolbox$ cat /var/tmp/cidfile  # still there!
2f8b3066a42d74b3278b732b336b4e7c9993c74d411a1d2f24a5badb8ecc1d92

But back on the host, our IMPORTANT DATA is gone.

host$ cat /var/tmp/cidfile
cat: /var/tmp/cidfile: No such file or directory

Describe the results you received

A file was inappropriately deleted on the container host and the cidfile remained present where podman-remote was running.

Describe the results you expected

I expected no files to be deleted.

podman info output

Both podman and podman-remote are from Fedora 39, version 4.9.3.

Podman in a container

Yes

Privileged Or Rootless

Rootless

Upstream Latest Release

Yes

Additional environment details

This is a normal toolbox environment on Fedora Silverblue 39.

Additional information

No response

[giuseppe]

I agree --cidfile doesn't seem to make sense with podman-remote, we should probably hide it.

[Luap99]

cidfile is fine, it is just that the server should never touch it as it is a client thing. It should never be send over the API.

[allisonkarlitskaya]

For the record, we use and need podman-remote run --cidfile. Please don't remove it. :)

[rhatdan]

Agree cidfile makes sense on remote.

[giuseppe]

yeah I got confused with pidfile. The cid makes sense

[github-actions]

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