Docker-mailserver: Amavis config file permissions not secure, keeps looping

[mattarnster]

When spawning a new docker-mailserver, amavis complains that its config file is writable and then exit-loops.

Context

I spawned a fresh copy of this docker container using the instructions in the readme.

Here's the log from the container:
```mail | Apr 5 01:42:49 amavis[167]: starting. /usr/sbin/amavisd-new at amavisd-new-2.10.1 (20141025), Unicode aware
mail | Apr 5 01:42:49 amavis[167]: Net::Server: Group Not Defined. Defaulting to EGID '111 111'
mail | Apr 5 01:42:49 amavis[167]: Net::Server: User Not Defined. Defaulting to EUID '109'
mail | Apr 5 01:42:49 amavis[167]: (!!)FATAL: Config file "/etc/amavis/conf.d/61-dms_auto_generated" is writable, UID 109, EUID 109, EGID 111 111
mail | Apr 5 01:42:49 amavis[167]: (!!)TROUBLE in pre_loop_hook: SECURITY PROBLEM, ABORTING at /usr/sbin/amavisd-new line 12567.
mail | 2020-04-05 01:42:49,623 INFO exited: amavis (exit status 255; not expected)

Not sure this is having an effect on me either way since spamassassin is disabled. 

## Expected Behavior
This shouldn't happen from a fresh `docker-compose up` command.

## Actual Behavior
See above for the log.

## Steps to Reproduce
Not sure how to reproduce, as this happened right from the start for me.

## Your Environment
<!--- Include as many relevant details about the environment you experienced the issue in -->
* Amount of RAM available: 12GB
* Mailserver version used: tvial/docker-mailserver:latest
* Docker version used: Docker version 1.13.1, build cccb291/1.13.1
* Environment settings relevant to the config:

HOSTNAME=
DOMAINNAME=
CONTAINER_NAME=mail

* Any relevant stack traces ("Full trace" preferred):
As log file above, copied below:
```mail    | Apr  5 01:42:49 <host> amavis[167]: starting. /usr/sbin/amavisd-new at <domain> amavisd-new-2.10.1 (20141025), Unicode aware
mail    | Apr  5 01:42:49 <host> amavis[167]: Net::Server: Group Not Defined.  Defaulting to EGID '111 111'
mail    | Apr  5 01:42:49 <host> amavis[167]: Net::Server: User Not Defined.  Defaulting to EUID '109'
mail    | Apr  5 01:42:49 <host> amavis[167]: (!!)FATAL: Config file "/etc/amavis/conf.d/61-dms_auto_generated" is writable, UID 109, EUID 109, EGID 111 111
mail    | Apr  5 01:42:49 <host> amavis[167]: (!!)TROUBLE in pre_loop_hook: SECURITY PROBLEM, ABORTING at /usr/sbin/amavisd-new line 12567.
mail    | 2020-04-05 01:42:49,623 INFO exited: amavis (exit status 255; not expected)

[aendeavor]

Was there some sort of insight, i.e. do you know more about this issue now?

[aendeavor]

This issue was closed due to one or more of the following reasons:

1. Age
2. Contributor inactivity
3. The issue seems to be resolved

If you think this happened by accident, or feel like this issue was not actually resolved, please feel free to re-open it. If there is an issue you could resolve in the meantime, please open a PR based on the current master branch so we can review it.

[artonge]

Hi,

I am having the same issue.

Problematic files are those copied from target here: https://github.com/tomav/docker-mailserver/blob/a0c2dc27c8cb75ef97308c3234945f26e116fa33/Dockerfile#L164

Maybe a chmod after the COPY could fix that ?

chmod go-w /etc/amavis/conf.d/*

But it is weird that no one else is complaining about that...

[aendeavor]

I've re-opened. But to be honest, this seems more of a configuration / setup error, since, as you mentioned, more users would report on this.

@erik-wramner any thoughts on this?

[artonge]

Ok, the problem might be with the way I build the image. I just built it locally and access rights seems to be ok.
I'll investigate more on Monday and write done what I found.

[erik-wramner]

@artonge do you build locally on Windows, by any chance? File permissions tend to go haywire for docker images built on Windows.

[artonge]

I am building on gitlab CI. Mabey their cloning strategy is weird

[erik-wramner]

Right. Please see suggestion in PR, if we add user (numeric) and permissions to the COPY command that should do the job!

[artonge]

After some debugging on the Gitlab CI, I can't reproduce the incorrect build, seems like a quantum bug...

Moreover, I don't think that the method suggested by @erik-wramner works, as it only change user and group and not file permissions.

I have at least changed the PR to be more predictable on the final file permissions, but I am not sure that it still need to be merged. I leave it up to you :).

Thanks for your work anyway !

[aendeavor]

Thanks for reporting back on this @artonge!

@erik-wramner I would leave it up to you to decide whether we merge this or not. I personally find your idea about the COPY command worth merging, but I guess you'd need to provide a PR for that on your own. I would not merge the current PR (since the problem you mentioned is actually still there) - if this helps you in finding the decision yourself. We can then close this and the PR (or merge it).