Podman replicates all artifacts in the "rootless_storage_path" to every account on BTRFS-based Linux workstation

[PavelSosin-320]

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind bug

Description

After playing with Podman under my own account on Fedora34 Workstation I found numerous subvolumes in the /.local/share/containers/storage of another user account created on the same workstation

Steps to reproduce the issue:

1. Login to the User account 1

2. Config storage.conf to use btrfs storage driver

3. Pull images and create containers

4. Swtch user via "Switch user" feature of GNOME - to the occasional user that has no idea what is Containers, OCI, Podman, etc.

5. Look at its $HOME/.local/user/share/containers/storage

Describe the results you received:
Many subvolumes representing OCI artifacts

Describe the results you expected:
Podman shall never replicated artifacts according user-level configuration depended on Is it security breach ( in the RedHat product )????
All artifacts are stored in the privately mounted on login subvolumes, like $XDG_DATA_HOME/containers/storage, unmounted on logout. Everything is left after switch user.
The same is true for for run_root see Managing temporary files using systemd

Additional information you deem important (e.g. issue happens only occasionally):
It happened only once. Subvolumes were not in libpodes.
Output of podman version:
podman version
ERRO[0000] User-selected graph driver "btrfs" overwritten by graph driver "overlay" from database - delete libpod local files to resolve
Version: 3.4.0
API Version: 3.4.0
Go Version: go1.16.8
Built: Thu Sep 30 22:40:21 2021
OS/Arch: linux/amd64

(paste your output here)

Output of podman info --debug:

RRO[0000] User-selected graph driver "btrfs" overwritten by graph driver "overlay" from database - delete libpod local files to resolve
host:
arch: amd64
buildahVersion: 1.23.1
cgroupControllers:

• memory
• pids
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
  package: conmon-2.0.30-2.fc34.x86_64
  path: /usr/bin/conmon
  version: 'conmon version 2.0.30, commit: '
  cpus: 8
  distribution:
  distribution: fedora
  variant: workstation
  version: "34"
  eventLogger: journald
  hostname: Dell
  idMappings:
  gidmap:
  • container_id: 0
    host_id: 1001
    size: 1
  • container_id: 1
    host_id: 165536
    size: 65536
    uidmap:
  • container_id: 0
    host_id: 1001
    size: 1
  • container_id: 1
    host_id: 165536
    size: 65536
    kernel: 5.13.14-200.fc34.x86_64
    linkmode: dynamic
    logDriver: k8s-file
    memFree: 259391488
    memTotal: 8178155520
    ociRuntime:
    name: crun
    package: crun-1.2-1.fc34.x86_64
    path: /usr/bin/crun
    version: |-
    crun version 1.2
    commit: 4f6c8e0583c679bfee6a899c05ac6b916022561b
    spec: 1.0.0
    +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
    os: linux
    remoteSocket:
    path: /run/user/1001/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: true
    serviceIsRemote: false
    slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.1.12-2.fc34.x86_64
    version: |-
    slirp4netns version 1.1.12
    commit: 7a104a101aa3278a2152351a082a6df71f57c9a3
    libslirp: 4.4.0
    SLIRP_CONFIG_VERSION_MAX: 3
    libseccomp: 2.5.0
    swapFree: 5267181568
    swapTotal: 8177840128
    uptime: 42h 36m 43.63s (Approximately 1.75 days)
    plugins:
    log:
• k8s-file
• none
• journald
  network:
• bridge
• macvlan
  volume:
• local
  registries:
  search:
• registry.fedoraproject.org
• registry.access.redhat.com
• docker.io
• quay.io
  store:
  configFile: /home/victoriakanevsky/.config/containers/storage.conf
  containerStore:
  number: 1
  paused: 0
  running: 0
  stopped: 1
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /home/victoriakanevsky/.local/share/containers/storage
  graphStatus:
  Backing Filesystem: btrfs
  Native Overlay Diff: "true"
  Supports d_type: "true"
  Using metacopy: "false"
  imageStore:
  number: 1
  runRoot: /run/user/1001/containers
  volumePath: /home/victoriakanevsky/.local/share/containers/storage/volumes
  version:
  APIVersion: 3.4.1
  Built: 1634740528
  BuiltTime: Wed Oct 20 17:35:28 2021
  GitCommit: ""
  GoVersion: go1.16.8
  OsArch: linux/amd64
  Version: 3.4.1

**Package info (e.g. output of `rpm -q podman` or `apt list podman`):**

podman-3.4.1-1.fc34.x86_64

**Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/master/troubleshooting.md)**


Yes/No

**Additional environment details (AWS, VirtualBox, physical, etc.):**

Plain Fedora 34 Workstation with 3 accounts

[giuseppe]

Podman shall never replicated artifacts according user-level configuration depended on Is it security breach ( in the RedHat product )????

The BTRFS backend is not supported in any Red Hat product. It is present only in the upstream project.

I had a quick look at the btrfs code and I don't see anywhere that could create subvolumes with a different user.

If you manually create a subvolume in the subvolumes directory in your user storage, does it get propagated to other users as well? If that happens, then it is out of the control of Podman

[rhatdan]

Could this be systemd restart script looking in all user accounts to see if they have a restart container waiting to start?

[PavelSosin-320]

Indeed, there are some created but not started at all. This is something very obvious: podman can't see them to start. When Podman runs on Fedora / Ubuntu workstation the Terminal is a plain graphic application inheriting its environment from the corresponding environment block of user's session service. The systemd-pam xdg helper must put everything that Podman needs to the systemd environment. There are many very strange things may happen if XDG environment variables have wrong values at the moment when Podman tries to create or use its artifacts in XDG_RUNTIME_DIR or XDG_DATA_HOME folders.
How it should work is here. I don't see it in reality.

[PavelSosin-320]

I see very strange thing: 2 folders under ... containers/storage/btrfs/ : subvomes and subvolums (older one). and error message when I'm trying to create container saying stat .. subvolumes/containerid doesn't exist. Indeed, the folder is empty. Does Podman knows where is its graph root shown as .local/share/container/storage ? When Podman runs on Ubuntu / Fedora Desktops it sees already created by systemd-homed file structure with btrfs subvolume (id 258) in addition to the /home (id256) created in the home area. The systemd-homed appears in systemd not so long time ago but now it is presented in Ubuntu, Suse, Fedora.
/home ... containers/storage/libpod folder ( not a subvolume ?) also has files.

[vrothberg]

As discussed in the other issue, the "switch user" thing in GNOME doesn't change XDG_ variables and is hence deemed to fail. Let's continue over in #12264 to consolidate the conversation a bit.

[PavelSosin-320]

Searching the possible solutions/workaround for the issues related to Podman I found funny thing: Fedora issues dashboard shows somes critical tickets related to Fedora rawhide Fedora rawhide issues <https://src.fedoraproject.org/tests/selinux/issues> related to SELinux. I use Fedora 35 upgraded to dev repositories, so it should work very similarly to Rawhide.If Podman integration tests run on the top of Fedora35 or Rawhide code line, including container/storage module https://github.com/containers/podman/tree/main/test the test results should show the same test failures because the scenario is pretty basic. . All issues reported by me are outcome of the single containers-storage problem containers/storage#1082 I hope that when container-storage integration with Fedora 35 will work Podman will have no issues. BR Pavel Sosin

…

On Mon, Dec 13, 2021 at 2:35 PM Valentin Rothberg ***@***.***> wrote: As discussed in the other issue, the "switch user" thing in GNOME doesn't change XDG_ variables and is hence deemed to fail. Let's continue over in #12264 <#12264> to consolidate the conversation a bit. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#12247 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AM7YVKHRRRJUPEZUNEQ372DUQXSCDANCNFSM5HXJCV4A> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.