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).
permissions on directory /var/mail remain unchanged across container restart
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
run _fix_var_mail_permissions() only if no real user and group IDs will be used
start the container
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
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.
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.