tomsquest / docker-radicale

Docker image for Radicale calendar and contact server :calendar: + security :closed_lock_with_key: + addons :rocket:
GNU General Public License v3.0
562 stars 80 forks source link

data folder on host has wrong owner #125

Closed eliasball closed 1 year ago

eliasball commented 1 year ago

Hey! First of all, thanks for making this, it has really come in handy for me!

However, I ran into a slight problem: I would like to protect my data folder on my host using chmod o=, but when I do this, I get an error from the radicale container that it can no longer read the folder.

Those are the permissions given to the folder when I change nothing: drwxrwxr-x 3 168534 168534 4096 Feb 5 18:13 data

I have also created a radicale user with uid and gid 2999. However, the folder does not seem to be owned by this user in the first place?

Do you have an idea what I am doing/understanding wrong?

For reference, my docker-compose.yml is the following:

version: '3.7'

services:
  radicale:
    image: tomsquest/docker-radicale
    container_name: radicale
    restart: unless-stopped
    ports:
      - 127.0.0.1:5232:5232
    init: true
    read_only: true
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL
    cap_add:
      - SETUID
      - SETGID
      - CHOWN
      - KILL
    volumes:
      - /path/to/radicale/data:/data
      - /path/to/radicale/config:/config:ro
      - /path/to/radicale/users:/users:ro
tomsquest commented 1 year ago

Hi @blue1stone

I run your docker-compose file and /path/to/radicale/data is owned by 2999:2999.

# docker-compose
    volumes:
      - /tmp/data:/data

# Volume
$ stat /tmp/data                                                                          
Access: (0755/drwxr-xr-x)  Uid: ( 2999/ UNKNOWN)   Gid: ( 2999/ UNKNOWN)

Maybe the problem is that /path/to/radicale/data was created before you run the container, so the folder is not owned by 2999. Only files inside will be owned by the user.

tomsquest commented 1 year ago

So you should/could chown it.

eliasball commented 1 year ago

Nope, that does sadly not fix the problem. Nor does disabling CHOWNing and setting the ownership on the folders beforehand myself.

I should probably mention that I am running the container as a non-root user, could this be the problem?

tomsquest commented 1 year ago

Ah, that is certainly the problem. The image is not made to be run as another user. Somehow the image will su to the radicale user. Here is an excerpt from entrypoint.sh

First, we reclaim the rights to the /data dir if running as root:

# If requested and running as root, mutate the ownership of bind-mounts
if [ "$(id -u)" = "0" ] && [ "$TAKE_FILE_OWNERSHIP" = "true" ]; then
    chown -R radicale:radicale /data
fi

And then we "switch" the user:

if [ "$(id -u)" = "0" ] && [ "$1" = "radicale" ]; then
    exec su-exec radicale "$@"
eliasball commented 1 year ago

Ahh alright, that explains it, thank you so much for your help! :D