[Bug]: graphroot and runroot default to current directory when running rootfull

[st3iny]

Issue Description

Both values graphroot and runroot default to the current directory when podman is run as root. There was a warning that graphroot defaults to some builtin value which vanished once I set a default in /etc/containers/storage.conf. The issue occured in both scenarios (config vs. no config and builtin default).

Steps to reproduce the issue

Steps to reproduce the issue

1. Explicitly configure graphroot and runroot to a fixed location in /etc/containers/storage.conf.
2. Run podman info.

Describe the results you received

Both configs graphroot and runroot are set to the current working directory. Podman creates a bunch of directories inside the current working directory.

btrfs
btrfs-containers
btrfs-images
btrfs-layers
btrfs-locks
mounts
storage.lock
tmp
userns.lock

Describe the results you expected

Podman should honor the settings from /etc/containers/storage.conf.

podman info output

host:
  arch: amd64
  buildahVersion: 1.28.0
  cgroupControllers:
  - cpuset
  - cpu
  - io
  - memory
  - hugetlb
  - pids
  - rdma
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: app-containers/conmon-2.0.30
    path: /usr/libexec/podman/conmon
    version: 'conmon version 2.0.30, commit: v2.0.30'
  cpuUtilization:
    idlePercent: 94.73
    systemPercent: 1.49
    userPercent: 3.78
  cpus: 12
  distribution:
    distribution: gentoo
    version: "2.9"
  eventLogger: journald
  hostname: xps
  idMappings:
    gidmap: null
    uidmap: null
  kernel: 6.1.9-gentoo-x86_64
  linkmode: dynamic
  logDriver: journald
  memFree: 9304436736
  memTotal: 33272430592
  networkBackend: cni
  ociRuntime:
    name: crun
    package: app-containers/crun-1.4.5
    path: /usr/bin/crun
    version: |-
      crun version 1.4.5
      commit: c381048530aa750495cf502ddb7181f2ded5b400
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
  os: linux
  remoteSocket:
    path: /run/podman/podman.sock
  security:
    apparmorEnabled: false
    capabilities: CAP_AUDIT_WRITE,CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_MKNOD,CAP_NET_BIND_SERVICE,CAP_NET_RAW,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: false
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: false
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: app-containers/slirp4netns-1.2.0
    version: |-
      slirp4netns version 1.2.0
      commit: 656041d45cfca7a4176f6b7eed9e4fe6c11e8383
      libslirp: 4.6.1
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.5.4
  swapFree: 38654701568
  swapTotal: 38654701568
  uptime: 0h 55m 58.00s
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  - ipvlan
  volume:
  - local
registries:
  search:
  - docker.io
store:
  configFile: /etc/containers/storage.conf
  containerStore:
    number: 2
    paused: 0
    running: 0
    stopped: 2
  graphDriverName: btrfs
  graphOptions: {}
  graphRoot: /root/podman-test
  graphRootAllocated: 984998739968
  graphRootUsed: 405837987840
  graphStatus:
    Build Version: Btrfs v6.0.2
    Library Version: "102"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 0
  runRoot: /root/podman-test
  volumePath: /var/lib/containers/storage/volumes
version:
  APIVersion: 4.3.1
  Built: 1675621454
  BuiltTime: Sun Feb  5 19:24:14 2023
  GitCommit: 814b7b003cc630bf6ab188274706c383f9fb9915
  GoVersion: go1.19.4
  Os: linux
  OsArch: linux/amd64
  Version: 4.3.1

Podman in a container

No

Privileged Or Rootless

Privileged

Upstream Latest Release

No

Additional environment details

No response

Additional information

This bug is supposed to be fixed according to #12467 and containers/storage#1083.

[st3iny]

One more thing: Running podman system reset deletes the contents of the current working directory which is very dangerous.

[st3iny]

I just compiled v4.4.0 from source and it's affected too.

[st3iny]

I manged to fix the issue. It turns out that there was some leftover state in /var/lib/containers (cache/blob-info-cache-v1.boltdb or storage/libpod/bolt_state.db). Removing the whole directory and creating it again did the trick.

[zouppen]

Should we reopen this bug? @st3iny was able to remove the cache, but the killer cache is still in the wild. I just wiped my hard drive because of this after running podman system reset. Seems to be related to btrfs storage.

Or is this fixed in containers/storage#1083 ?

[rhatdan]

We prefer new bugs with new repeaters rather then opening an existing closed but. Often the symptoms are slightly different.