Docker-mailserver: save failed to INBOX: open(/var/mail/...) Permission denied

Created on 12 Jun 2018  路  6Comments  路  Source: tomav/docker-mailserver

Description

The function "_fix_var_mail_permissions()" from startup script "target/start-mailserver.sh" breaks postfix and dovecot.
From LDAP the real uidNumber and gidNumber will be provided to postfix und dovecot. So both processes run into trouble as long all ownership in /var/mail belongs to uid 5000 (always set by the function above).

Expected Behavior

permissions on directory /var/mail remain unchanged across container restart

Actual Behavior

Jun 11 22:41:59 docker-mailserver dovecot: lmtp([email protected]): Error: open(/var/mail/werni.de/ftp/tmp/1528756919.M184564P1999.docker-mailserver) failed: Permission denied
Jun 11 22:41:59 docker-mailserver dovecot: lmtp([email protected]): msgid=<[email protected]>: save failed to INBOX: open(/var/mail/werni.de/ftp/tmp/1528756919.M184564P1999.docker-mailserver) failed: Permission denied

Possible Fix

run _fix_var_mail_permissions() only if no real user and group IDs will be used

Steps to Reproduce

start the container

Your Environment

  • Mailserver version used: latest 2018-06-02T19:16:20.271Z
  • Environment settings relevant to the config:
    env:
      OVERRIDE_HOSTNAME: "mail.werni.de"
      SSL_TYPE: "manual"
      SSL_CERT_PATH: "/tmp/ssl/fullchain.pem"
      SSL_KEY_PATH: "/tmp/ssl/privkey.pem"
      ENABLE_SPAMASSASSIN: 1
      ENABLE_CLAMAV: 1
      ENABLE_FAIL2BAN: 1
      ENABLE_POSTGREY: 1
      ONE_DIR: 1
      DMS_DEBUG: 1
      ENABLE_LDAP: 1
      LDAP_SERVER_HOST: "{{ LDAP_VIRTUAL_HOST }}" # your ldap container/IP/ServerName
      LDAP_SEARCH_BASE: "ou={{ LDAP_OU_USERS }},{{ LDAP_BASE_DN }}"
      LDAP_BIND_DN: "cn={{ LDAP_READONLY_USER_USERNAME }},{{ LDAP_BASE_DN }}"
      LDAP_BIND_PW: "{{ LDAP_READONLY_USER_PASSWORD }}"
      LDAP_QUERY_FILTER_USER: "(mail=%s)"
      LDAP_QUERY_FILTER_GROUP: "(&(mailGroupMember=%s)(mailenable=TRUE))"
      LDAP_QUERY_FILTER_ALIAS: "(mailalias=%s)"
      LDAP_QUERY_FILTER_DOMAIN: "(&(|(mail=*@%s)(mailalias=*@%s)(mailGroupMember=*@%s))(mailEnabled=TRUE))"
      DOVECOT_TLS: 1
      DOVECOT_PASS_FILTER: "(&(uid=%n)(objectClass=posixAccount))"
      DOVECOT_USER_FILTER: "(&(uid=%n)(objectClass=person))"
      ENABLE_SASLAUTHD: 1
      SASLAUTHD_LDAP_SSL: yes
      SASLAUTHD_MECHANISMS: ldap
      SASLAUTHD_LDAP_SERVER: "{{ LDAP_VIRTUAL_HOST }}" # your ldap container/IP/ServerName
      SASLAUTHD_LDAP_BIND_DN: "cn={{ LDAP_READONLY_USER_USERNAME }},{{ LDAP_BASE_DN }}"
      SASLAUTHD_LDAP_PASSWORD: "{{ LDAP_READONLY_USER_PASSWORD }}"
      SASLAUTHD_LDAP_SEARCH_BASE: "ou={{ LDAP_OU_USERS }},{{ LDAP_BASE_DN }}"
      SASLAUTHD_LDAP_FILTER: "(&(uid=%U)(objectClass=person))"
      POSTMASTER_ADDRESS: [email protected]
    capabilities:
      - NET_ADMIN
      - SYS_PTRACE
bug help wanted ldap related priority 3 [LOW] stale waiting for contributor action

Most helpful comment

I don't use LDAP, so I'm not familiar with that setup. However, in general it feels a bit scary. We use virtual mailboxes with a common user id, which means all daemons (postfix, dovecot, backup scripts, ...) can access the files. Fixing the ownership at startup helps in some situations with mounted storage in Kubernetes and after a restore. If we remove that we can break things.

Again, as I'm not using LDAP I can't tell if this would be an improvement or if it would create problems. However, considering that there are many others who are using LDAP successfully in spite of this (seemingly breaking?) problems I'm worried that it might cause more issues than it solves.

I vote for having an explicit option that is off (backwards compatible) by default.

All 6 comments

Can you provide a PR?

I have added a fix to my repo with an env var SKIP_PERMISSIONS_CHECK

you can also fix this issue by using - DOVECOT_USER_ATTRS

you do need the =var= as per this

- DOVECOT_USER_ATTRS=homeDirectory=home,=uid=5000,=gid=5000

@Kramins is a PR necessary, and could you provide one if so? I would like to close this, but I'm not sure whether this is through.

Hi, I have the permission problem as well.

As far as i figured out it is because of the "_fix_var_mail_permissions" in the start_mailserver.sh (line 1817) function.

I am using an OpenLDAP for my user management so setting the owner to 5000 on every startup locks out my ldap users and I cant use the server after a reboot/ docker recreation unless i set all permission manually back to each userid i use in ldap.

could you include either a variable to disable the "fix" or just disable, if ldap is used?

Thanks for your great work!

Hey @gollywood.

Your idea of disabling it when ENABLE-LDAP=1 seems sufficient to me. But I'll double check it by asking @erik-wramner.

@erik-wramner what do think about this idea?

I don't use LDAP, so I'm not familiar with that setup. However, in general it feels a bit scary. We use virtual mailboxes with a common user id, which means all daemons (postfix, dovecot, backup scripts, ...) can access the files. Fixing the ownership at startup helps in some situations with mounted storage in Kubernetes and after a restore. If we remove that we can break things.

Again, as I'm not using LDAP I can't tell if this would be an improvement or if it would create problems. However, considering that there are many others who are using LDAP successfully in spite of this (seemingly breaking?) problems I'm worried that it might cause more issues than it solves.

I vote for having an explicit option that is off (backwards compatible) by default.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

jholster picture jholster  路  4Comments

cottonthread picture cottonthread  路  4Comments

rwarren picture rwarren  路  4Comments

ShuP1 picture ShuP1  路  4Comments

Mathieu-R picture Mathieu-R  路  4Comments