Inconsistencies when mounting /run

[nolange]

Issue Description

There are some slight variations whether a user mounts a tmpfs in /run, the documentation is vague or incorrect. So this bug more or less should the problem but cant tell whether this is working as intended - then the documentation should be more explicit.

There are a few switches which mount stuff in /run (--init, --secret). It should be able to reduce side-effects and documentation if things just work as expected (ie. functionality is not affected whether /run is a tmpfs or not).
It should be possible to run mounts in the correct order, or atleast detect and report if previous stuff gets undone by a mount.

Some additional guidance in the docs would be welcome, I would prefer /run to always be a tmpfs. It seems to make sense to hide this in a private tmpfs that is not backed by a blockdevice.

Steps to reproduce the issue

Steps to reproduce the issue

1. run commands in the form of podman run --rm debian ls -la /run

Describe the results you received

Inconsistencies whether /run/.containerenv is mounted, inconsistencies with the docs as --init still works.

command	result	comment
podman run --rm debian ls -la /run	/run/.containerenv is mounted
podman run --rm --tmpfs=/run debian ls -la /run	/run/.containerenv is not mounted
podman run --rm --tmpfs=/run --init debian ls -la /run	/run/.containerenv is not mounted, /run/podman-init exists	the documentation states this shouldnt work
podman run --rm --systemd=always debian ls -la /run	/run/.containerenv is mounted
podman run --rm --read-only debian ls -la /run	/run/.containerenv is not mounted

Describe the results you expected

Everything working the same, no matter which way you end up with a tmpfs on /run.
Everything working the same, no matter whether you mount tmpfs on /run (as long as technically possible of course).
The documentation reflecting this

podman info output

host:
  arch: amd64
  buildahVersion: 1.28.2
  cgroupControllers:
  - memory
  - pids
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon_2.1.6+ds1-1_amd64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.6, commit: unknown'
  cpuUtilization:
    idlePercent: 92.33
    systemPercent: 1.6
    userPercent: 6.07
  cpus: 4
  distribution:
    codename: bookworm
    distribution: debian
    version: "12"
  eventLogger: journald
  hostname: lano-work
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  kernel: 6.1.0-8-amd64
  linkmode: dynamic
  logDriver: journald
  memFree: 12309508096
  memTotal: 16721424384
  networkBackend: netavark
  ociRuntime:
    name: crun
    package: crun_1.8.1-1+b1_amd64
    path: /usr/bin/crun
    version: |-
      crun version 1.8.1
      commit: f8a096be060b22ccd3d5f3ebe44108517fbf6c30
      rundir: /run/user/1000/crun
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
  os: linux
  remoteSocket:
    path: /run/user/1000/podman/podman.sock
  security:
    apparmorEnabled: false
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: true
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: false
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns_1.2.0-1_amd64
    version: |-
      slirp4netns version 1.2.0
      commit: 656041d45cfca7a4176f6b7eed9e4fe6c11e8383
      libslirp: 4.7.0
      SLIRP_CONFIG_VERSION_MAX: 4
      libseccomp: 2.5.4
  swapFree: 5295300608
  swapTotal: 5295300608
  uptime: 1h 32m 39.00s (Approximately 0.04 days)
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  volume:
  - local
registries:
  10.99.11.2:5050:
    Blocked: false
    Insecure: true
    Location: 10.99.11.2:5050
    MirrorByDigestOnly: false
    Mirrors: null
    Prefix: 10.99.11.2:5050
    PullFromMirror: ""
store:
  configFile: /home/lano/.config/containers/storage.conf
  containerStore:
    number: 0
    paused: 0
    running: 0
    stopped: 0
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /home/lano/.local/share/containers/storage
  graphRootAllocated: 234068783104
  graphRootUsed: 114896093184
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 12
  runRoot: /run/user/1000/containers
  volumePath: /home/lano/.local/share/containers/storage/volumes
version:
  APIVersion: 4.3.1
  Built: 0
  BuiltTime: Thu Jan  1 01:00:00 1970
  GitCommit: ""
  GoVersion: go1.19.6
  Os: linux
  OsArch: linux/amd64
  Version: 4.3.1

Podman in a container

No

Privileged Or Rootless

Rootless

Upstream Latest Release

No

Additional environment details

Additional environment details

Additional information

Additional information like issue happens only occasionally or issue happens with a particular architecture or on a particular setting

[rhatdan]

Nice detective work, interested in opening a PR to fix. I think in all cases, with the possible exception of --read-only we should mount /run/.containerenv (If /run is on the read-only share, then we should not mount on it unless /run/.containerenv exists.) if /run is a tmpfs we should always mount it.

[nolange]

--read-only still mounts a tmps on /run (at least by default).

[rhatdan]

I took a quick look and found a fix, #18535

[nolange]

Err... I thought the most reasonable thing would be to provide /run/.containerenv always, /run/podman-initwhen --init is specified and /run/secrets when those are needed.
Whats the argument for this special case stuff? Even files that pe-exist in the container filesystem will be "copied up" when you mount a tmpfs normally, this is completely different to everything else?

[rhatdan]

I don't think we should create content on a volume that is mounted at /run. Never have in the past, so I would see this as a breaking change. Potentially you could have the source volume be read-only also.

[nolange]

I don't think we should create content on a volume that is mounted at /run. Never have in the past, so I would see this as a breaking change. Potentially you could have the source volume be read-only also.

You already did in the past, see the opening comment.

And I dont talk about arbitrary volume mounts, but a tmpfsspecifically. Whatever you do on the rootfs can be done on a tmpfs mount aswell - and for consistency you should.

If you follow your own logic, you must not create content on /run if --systemd=always is set (or --systemd=true and a fitting cmdline). So stuff like secrets wouldn't work either. I hope you agree that would be weird.

That's a ton of special cases, vs things just working the same (aslong as technically feasible).

To be more exact: "systemd mode mount" , --read-only with --read-only-tmpfs=true and --tmpfs=/run should end up with the same observations in regards to /run (and the podman features like --initand --secret).

I see it functionally just as doing a tmpcopyup of the things you would otherwise do to the underlying rootfs.
If there is a case when to disable content creation then I would tie it to the notmpcopyup flag.