Skip to content

bug report: SELinux incompatibility using named volumes #3887

@robbertkl

Description

@robbertkl

📝 Preliminary Checks

  • I tried searching for an existing issue and followed the debugging docs advice, but still need assistance.

👀 What Happened?

On my FedoraCoreOS host, SELinux is enabled ("enforcing") by default, and I run into some issues with docker-mailserver on my setup, using named volumes (see config below). Initial startup is good, but when the container is recreated (e.g. docker compose up -d --force-recreate mail) it breaks (see logs below).

I understand this might be out of scope as it concerns SELinux, but would still like to check if this is not somehow an issue with the image, as it only affects 1 of the volumes (mail-state).

Workaround where it doesn't break:

  • Disabling SELinux system wide (sudo setenforce 0)
  • Running the container privileged (privileged: true in compose.yaml)
  • Disabling SELinux for the container (security_opt: - label:disable in compose.yaml)

Interestingly, adding bind option :z or :Z to the mounts (which is the suggested solution in many places) does not help; it looks like it's not used/allowed for named volumes (only bind mounts) which is why compose warns about that in some of its commands.

Other than disabling SELinux I don't have a solution for this. I can see the directories within mail-state are improperly labeled and I also cannot access them using docker exec. However, other volumes like mail-data also get some automatically created dirs, but they are labeled system_u:object_r:container_file_t:s0 and can be accessed without issues:

# ls -Z /var/mail /var/mail-state | cat
/var/mail:
system_u:object_r:container_file_t:s0 example.com

/var/mail-state:
system_u:object_r:container_file_t:s0:c1022,c1023 lib-dovecot
system_u:object_r:container_file_t:s0:c1022,c1023 lib-fail2ban
system_u:object_r:container_file_t:s0:c1022,c1023 lib-logrotate
system_u:object_r:container_file_t:s0:c1022,c1023 lib-postfix
system_u:object_r:container_file_t:s0:c1022,c1023 lib-redis
system_u:object_r:container_file_t:s0:c1022,c1023 lib-rspamd
system_u:object_r:container_file_t:s0:c1022,c1023 spool-postfix

Anything special about the way mail-state is initially provisioned that makes it behave in this way? Any clue why I don't have this issue with the other named volumes?

👟 Reproduction Steps

No response

🐋 DMS Version

v13.3.1

💻 Operating System and Architecture

FedoraCoreOS 39 x86_64

⚙️ Container configuration files

volumes:
  # ...
  letsencrypt:
    name: letsencrypt
  mail-data:
    name: mail-data
  mail-state:
    name: mail-state
  mail-logs:
    name: mail-logs
  mail-config:
    name: mail-config

services:
  # ...
  mail:
    container_name: mail
    image: mailserver/docker-mailserver
    hostname: ######
    restart: always
    cap_add:
      - NET_ADMIN
    ports:
      - '25:25'
      - '465:465'
      - '587:587'
      - '993:993'
    volumes:
      - mail-data:/var/mail
      - mail-state:/var/mail-state
      - mail-logs:/var/log/mail
      - mail-config:/tmp/docker-mailserver
      - letsencrypt:/etc/letsencrypt
    environment:
      ENABLE_RSPAMD: 1
      ENABLE_FAIL2BAN: 1
      ENABLE_CLAMAV: 0
      ENABLE_OPENDMARC: 0
      ENABLE_OPENDKIM: 0
      ENABLE_POLICYD_SPF: 0
      ENABLE_AMAVIS: 0
      ENABLE_SPAMASSASSIN: 0
      ENABLE_UPDATE_CHECK: 0
      DOVECOT_MAILBOX_FORMAT: mdbox
      SSL_TYPE: letsencrypt
      SPOOF_PROTECTION: 1
      MOVE_SPAM_TO_JUNK: 1
      MARK_SPAM_AS_READ: 1
      RSPAMD_LEARN: 1
      TZ: Europe/Amsterdam

📜 Relevant log output

[   INF   ]  Welcome to docker-mailserver v13.3.1
[   INF   ]  Checking configuration
[   INF   ]  Configuring mail server
chown: cannot read directory '/var/mail-state/lib-rspamd': Permission denied
chown: cannot read directory '/var/mail-state/lib-redis': Permission denied
chown: cannot read directory '/var/mail-state/lib-logrotate': Permission denied
chown: cannot read directory '/var/mail-state/lib-postfix': Permission denied
chown: cannot read directory '/var/mail-state/spool-postfix': Permission denied
chown: changing ownership of '/var/mail-state/spool-postfix': Permission denied
chgrp: cannot access '/var/mail-state/spool-postfix/maildrop': Permission denied
chgrp: cannot access '/var/mail-state/spool-postfix/public': Permission denied
chmod: cannot access '/var/mail-state/spool-postfix/maildrop': Permission denied
chmod: cannot access '/var/mail-state/spool-postfix/public': Permission denied
rm: cannot remove '/var/mail-state/spool-postfix/dev': Permission denied
rm: cannot remove '/var/mail-state/spool-postfix/etc': Permission denied
rm: cannot remove '/var/mail-state/spool-postfix/lib': Permission denied
rm: cannot remove '/var/mail-state/spool-postfix/pid': Permission denied
rm: cannot remove '/var/mail-state/spool-postfix/usr': Permission denied
rm: cannot remove '/var/mail-state/spool-postfix/private/auth': Permission denied
[   INF   ]  Starting daemons
[   INF   ]  ###### is up and running
Feb 12 21:36:12 mail postfix[858]: fatal: chdir(/var/spool/postfix): Permission denied
Feb 12 21:36:17 mail postfix[983]: fatal: chdir(/var/spool/postfix): Permission denied
Feb 12 21:36:22 mail postfix[1086]: fatal: chdir(/var/spool/postfix): Permission denied
...

Improvements to this form?

No response

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions