Shared Volume getting Z propogation and permission denied in container

[kevinelliott]

Strangely, when defining a shared volume (by defining it in the root level volumes and then referencing it in each service):

version: '3'
services:
  flightaware-dump1090:
    container_name: flightaware-dump1090
    image: boxel/flightaware-dump1090:latest
    hostname: slim2-flightaware-dump1090
    ports:
      - "30002:30002"
      - "30003:30003"
      - "30005:30005"
    args:
      - LATITUDE=38.672
      - LONGITUDE=-121.091
    volumes:
      - run-dump1090-fa:/run/dump1090-fa
    devices:
      - /dev/bus/usb/001/005:/dev/bus/usb/001/005
    networks:
      primary:
        ipv4_address: 172.168.238.10
    restart: unless-stopped

  flightaware-skyview1090:
    container_name: flightaware-skyview1090
    image: boxel/flightaware-skyview1090:latest
    hostname: slim2-flightaware-skyview1090
    depends_on:
      - flightaware-dump1090
    ports:
      - "8080:80"
    args:
      - LATITUDE=38.672
      - LONGITUDE=-121.091
    volumes:
      - run-dump1090-fa:/run/dump1090-fa
    networks:
      primary:
        ipv4_address: 182.168.238.11
    restart: unless-stopped
volumes:
  run-dump1090-fa:
networks:
  primary:
    ipam:
      driver: default
      config:
        - subnet: "172.16.238.0/24"

... the services are binding the shared volume with propagation Z which makes it private and unshared. The second service to mount wins, and the first no longer has access.

Looking at the source at

podman-compose/podman_compose.py

Line 390 in 4c07e87

ret["bind"]["propagation"]="Z"

reveals that as long as the volume exists in shared_vols (which is defined from the root volumes element in the docker-compose.yml), then it should get z instead of Z.

However, you can see from the podman create runs that it's passing Z:

podman volume inspect root_run-dump1090-fa || podman volume create root_run-dump1090-fa
podman run --name=flightaware-dump1090 -d --pod=root -l io.podman.compose.config-hash=123 -l io.podman.compose.project=root -l io.podman.compose.version=0.0.1 -l com.docker.compose.container-number=1 -l com.docker.compose.service=flightaware-dump1090 --device /dev/bus/usb/001/005:/dev/bus/usb/001/005 --mount type=bind,source=/var/lib/containers/storage/volumes/root_run-dump1090-fa/_data,destination=/run/dump1090-fa,bind-propagation=Z --add-host flightaware-dump1090:127.0.0.1 --add-host flightaware-dump1090:127.0.0.1 --add-host flightaware-skyview1090:127.0.0.1 --add-host flightaware-skyview1090:127.0.0.1 --hostname slim2-flightaware-dump1090 boxel/flightaware-dump1090:latest
247e57c92ea32d8138277a11f509668802cd123a51157831b5b20c47df026f82
0
podman volume inspect root_run-dump1090-fa || podman volume create root_run-dump1090-fa
podman run --name=flightaware-skyview1090 -d --pod=root -l io.podman.compose.config-hash=123 -l io.podman.compose.project=root -l io.podman.compose.version=0.0.1 -l com.docker.compose.container-number=1 -l com.docker.compose.service=flightaware-skyview1090 --mount type=bind,source=/var/lib/containers/storage/volumes/root_run-dump1090-fa/_data,destination=/run/dump1090-fa,bind-propagation=Z --add-host flightaware-dump1090:127.0.0.1 --add-host flightaware-dump1090:127.0.0.1 --add-host flightaware-skyview1090:127.0.0.1 --add-host flightaware-skyview1090:127.0.0.1 --hostname slim2-flightaware-skyview1090 boxel/flightaware-skyview1090:latest
0c2bb6eade87ef844d39801afed31ee5ca361968ea94fcbc37d2a705099059a8

Also, upon inspection of the containers with podman inspect, only the second container actually has a Mounts element listed, and it has propagation listed as rprivate, which would restrict to that container.

        "Mounts": [
            {
                "Type": "bind",
                "Name": "",
                "Source": "/var/lib/containers/storage/volumes/root_run-dump1090-fa/_data",
                "Destination": "/run/dump1090-fa",
                "Driver": "",
                "Mode": "",
                "Options": [
                    "rbind"
                ],
                "RW": true,
                "Propagation": "rprivate"
            }
        ],

The first container has no Mounts at all.

[kevinelliott]

Temporary solution was to define volume-name:/path/in/container:z on the volumes in each service and it was passed through successfully.

But, that doesn't explain why the original logic failed to detect the root volumes item properly and instead defaulted to Z, so this should still be looked at.

[muayyad-alsadi]

My current implementation of volumes has some serious bugs that I'm planning to solve tomorrow

Converting volumes to bind make podman volume prune unaware of that and remove them.

My understanding of considering shared if it's volumes section is wrong, docker-compose consider it illegal to reference a volume that is not in volumes section

[muayyad-alsadi]

the bug is a side effect of an issue asking to prefix volumes with project name,

if vol_name in shared_vols:

is expecting to find vol2_run-dump1090-fa in a set of {'run-dump1090-fa'}

I'm pushing a temporal fix

[kevinelliott]

Ah ha, that explains it!

[muayyad-alsadi]

would you please help me test this branch

https://github.com/containers/podman-compose/tree/feature/pass-volumes

pip3 install https://github.com/containers/podman-compose/archive/feature/pass-volumes.zip

I wonder if bind-propagation=z works if --mount type=volume

podman run --mount type=volume,source=vol2_run-dump1090-fa,destination=/run/dump1090-fa,bind-propagation=z

should it be bind-propagation=z

[mheon]

No need for the bind-propagation part. Just adding z to --mount will do it.
podman run type=volume,source=vol2_run-dump1090-fa,destination=/run/dump1090-fa,z for example.

[muayyad-alsadi]

@mheon does this apply to mount_type=bind? because the docs says it's type=bind,...,bind-propagation=z

type=bind,source=/path/on/host,destination=/path/in/container

                 type=tmpfs,tmpfs-size=512M,destination=/path/in/container
                 Common Options:

                    · src, source: mount source spec for bind and volume. Mandatory for bind.
                    · dst, destination, target: mount destination spec.
                    · ro, read-only: true or false (default).

                 Options specific to bind:

                    · bind-propagation: Z, z, shared, slave, private, rshared, rslave, or rprivate(default). See also mount(2).
                    . bind-nonrecursive: do not setup a recursive bind mount.  By default it is recursive.

[rhatdan]

If you want to share an volume between multiple containers, then you use "z" if you want it private to one container then it is "Z".

[muayyad-alsadi]

@rhatdan yes we know, the question is how to pass "z" or "Z" for bind and for volume (should we prefix it with bind-propagation=<X>)

for example:

• --mount type=bind,source=/dir1,destination=/target,z
• --mount type=volume,source=vol1,destination=/target,z

or

• --mount type=bind,source=/dir1,destination=/target,bind-propagation=z
• --mount type=volume,source=vol1,destination=/target,bind-propagation=z

or

• --mount type=bind,source=/dir1,destination=/target,bind-propagation=z
• --mount type=volume,source=vol1,destination=/target,volume-propagation=z

or

• --mount type=bind,source=/dir1,destination=/target,bind-propagation=z
• --mount type=volume,source=vol1,destination=/target,z

[mheon]

Hmm. The code won't handle bind-propagation=z right now, which sounds like a bug. Easy enough to fix.

…

On Sun, Sep 15, 2019, 08:35 Muayyad Alsadi ***@***.***> wrote: @rhatdan <https://github.com/rhatdan> yes we know, the question is how to pass "z" or "Z" is it for bind and for volume (should we prefix it with bind-propagation=<X>) for example: - --mount type=bind,source=/dir1,destination=/target,z - --mount type=volume,source=vol1,destination=/target,z or - --mount type=bind,source=/dir1,destination=/target,bind-propagation=z - --mount type=volume,source=vol1,destination=/target,bind-propagation=z or - --mount type=bind,source=/dir1,destination=/target,bind-propagation=z - --mount type=volume,source=vol1,destination=/target,volume-propagation=z or - --mount type=bind,source=/dir1,destination=/target,bind-propagation=z - --mount type=volume,source=vol1,destination=/target,z — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#41?email_source=notifications&email_token=AB3AOCCJJRSJPD55NOTKXE3QJYTYPA5CNFSM4IWT6PB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6XP4MQ#issuecomment-531562034>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB3AOCCKDCHBFZANXOK5PH3QJYTYPANCNFSM4IWT6PBQ> .

[rhatdan]

I would have thought --mount type=volume,source=vol1,destination=/target,z but this does not work. I am not sure if podman --mount handles the relabel at all.

[rhatdan]

I would think the proper way to handle this would be to add relabel=private, relabel=shared, relabel=none.

[muayyad-alsadi]

https://docs.docker.com/storage/bind-mounts/

• The bind-propagation option, if present, changes the bind propagation. May be one of rprivate, private, rshared, shared, rslave, slave.
• The --mount flag does not support z or Z options for modifying selinux labels.

should I revert to -v instead of --mount?

[groovyman]

Please be so kind, and update/describe also the compose.yaml file with its volumes: section. The origin docker-compose comes with a lot of variations to delcare volumes in version 3.
Actually, i can not figure out, how to identify the host source-directory of the volumes myvol1 oder myvol2 named volumes inside the docker-compose.yaml

I started on F31 with this volume bind:

    image: "postgres:9.6"
    environment:
      POSTGRES_USER: awx
      POSTGRES_PASSWORD: awxpass
      POSTGRES_DB: awx
      PGDATA: /var/lib/postgresql/pgdata
    volumes:
      - /home/cgroove/Temp/Databasefiles/postgresql:/var/lib/postgresql:Z

and learned in this issue, that i should use the volume syntax while reading @kevinelliott posting.Unfortunately i ended up in the well kown relabeling issue. So, what would be the out-of-box workaround with named volumes?

[Richard87]

I have the same problem with bitnami/mysql, the process runs with UID 1001 ( as reported inside the container), but the volume is mounted with the root as owner, and with readonly:

podman run --rm -it --mount type=bind,source=/media/containers/podman/richard/storage/volumes/api_db/_data,destination=/bitnami/mysql,bind-propagation=z bitnami/mysql:5.7 bash

mysql 14:55:41.41 
mysql 14:55:41.41 Welcome to the Bitnami mysql container
mysql 14:55:41.41 Subscribe to project updates by watching https://github.com/bitnami/bitnami-docker-mysql
mysql 14:55:41.41 Submit issues and feature requests at https://github.com/bitnami/bitnami-docker-mysql/issues
mysql 14:55:41.41 Send us your feedback at containers@bitnami.com
mysql 14:55:41.41 

1001@15dc89c7d81c:/$ ls -la /bitnami/mysql 
total 8
drwxr-xr-x 2 root root 4096 Jan  2 12:57 .
drwxr-xr-x 3 root root 4096 Jan  2 06:56 ..
1001@15dc89c7d81c:/$ echo $UID
1001
1001@15dc89c7d81c:/$ 

My docker compose file:

version: "3.5"

services:
  db:
    restart: unless-stopped
    image: bitnami/mysql:5.7
    ports:
      - 127.0.0.1:3309:3306
    environment:
      - MYSQL_ROOT_PASSWORD=xxx
      - MYSQL_DATABASE=xxx
    volumes:
      - db:/bitnami/mysql
volumes:
  db: ~