Executing podman: Permission denied

Hello everyone,

I have been puzzling for a few days now why I always get the following error message when I want to start my Django project:

[db]  | chmod: changing permissions of '/var/lib/postgresql/data': Permission denied
[db]  | find: ‘/var/lib/postgresql/data’: Permission denied
[db]  | chown: changing ownership of '/var/lib/postgresql/data': Permission denied
[web] | python: can't open file '/code/manage.py': [Errno 13] Permission denied
ls -la
total 20
drwxr-xr-x. 1 tealk tealk 152 30. Jul 08:18 .
drwxr-xr-x. 1 tealk tealk 614 30. Jul 08:03 ..
drwxr-xr-x. 1 tealk tealk   4 30. Jul 08:08 data
-rw-r--r--. 1 tealk tealk 165 30. Jul 08:04 Dockerfile
-rw-r--r--. 1 tealk tealk 129 30. Jul 07:54 .env
-rwxr-xr-x. 1 tealk tealk 671 30. Jul 08:18 manage.py
-rw-r--r--. 1 tealk tealk 530 30. Jul 08:08 podman-compose.yml
-rw-r--r--. 1 tealk tealk  30 30. Jul 08:04 requirements.txt
drwxr-xr-x. 1 tealk tealk  86 30. Jul 08:18 djangotest
# djangotest/podman-compose.yml
services:
  db:
    image: postgres
    volumes:
      - ./data/db:/var/lib/postgresql/data
    environment:
      - POSTGRES_DB=${PostgreSQL_NAME}
      - POSTGRES_USER=${PostgreSQL_USER}
      - POSTGRES_PASSWORD=${PostgreSQL_PASSWORD}

  web:
    build: .
    command: >
             python manage.py makemigrations &&
             python manage.py migrate &&
             python manage.py runserver 0.0.0.0:8000
    volumes:
      - .:/code
    ports:
      - "8000:8000"
    env_file:
      - .env
    depends_on:
      - db
# djangotest/Dockerfile
FROM python:3

ENV PYTHONDONTWRITEBYTECODE=1

ENV PYTHONUNBUFFERED=1

WORKDIR /code

COPY requirements.txt /code/

RUN pip install -r requirements.txt

COPY . /code/
# djangotest/requirements.txt
Django>=3.0,<4.0
psycopg2>=2.8
# djangotest/manage.py
standard content

I can only infer you have a problem with selinux. You are mounting some hostpath to containers. When doing this, you need to label the path so that a container is able to access it based on current selinux policies. You can label the path manually, but in docker/podman there is an auto-relabelling mechanism via the z/Z letter at the end of the mountpoint like so:

    volumes:
      - ./hostpath:/container_mountpoint:z

so add “:z” at the end of your volume definitions and redeploy and see if the problem is coming from here. When inspecting the hostpath with ls -laZ you will notice the selinux label changed.

2 Likes

Thanks, that works, how can I make sure that I can still edit the data in the folder?
Currently, an unknown user is stored as the owner of the folder

Added postgresql, selinux

Hi @tealk

It is true, very often in development mode you tend to make changes to the containers storage while it is running. Very often we create docker/podman-compose setups to simulate as closely as possible the production runtime with networks etc. Or maybe you just want to connect pgadmin to your container so that you can query the db while it is running.

However one important idea here is that containers were designed to be a contained process that should not easily get access to host, for security reasons. So in development mode we are starting to see all sorts of blockages - but let’s get back to your concrete problem.

That “unknown” user should be a number from a range specified in your host system “/etc/subuid” file. Go ahead and cat this file and you will notice something like “myuser:startrange:endrange”. So the uid you see with ls -laZ should be from that range… So podman is creating a temporary user from that range. This is the base linux security model - something called Discretionary Access Control (DAC) - which means that every process is allowed to access only what it owns, not more than that. This specific feature from /etc/subuid is called “User Namespaces”. Every time you restart your podman, it will assign a new user and this is part of security. You could “sudo chown myuser:myuser /myfolder” so that you can edit the file from your host but this will mean that you will edit the file from the host but then the container process might fail again because the file ownership changed etc.

You could do something like

sudo podman-compose up

then the folder will not be owned by a dynamic user but by your direct linux user… so you will need to start your edit process in privileged mode like in the case of visual studio code:

sudo code --no-sandbox --user-data-dir /home/MYUSER

then click file/openfolder and find your db folder… but this will be only for development purposes… I hope this wasnt’t too confusing…

1 Like