Beats: docker images for APM Server failing with permission issues

[simitt]

It seems that with introducing changes in https://github.com/elastic/beats/pull/12905 config file permissions were changed from 0640 to 0660.

When running the APM Server docker images without setting BEAT_STRICT_PERMS=false the check OwnerHasExclusiveWritePerms now fails with the error config file ("apm-server.yml") can only be writable by the owner but the permissions are "-rw-rw----". Our integration test environment fails since pulling in these changes into APM Server.

It seems to be the same issue for other beats, e.g. running docker run -e docker.elastic.co/beats/metricbeat:8.0.0-SNAPSHOT results in the mentioned error and prevents the beat from starting, whereas docker run -e BEAT_STRICT_PERMS=false docker.elastic.co/beats/metricbeat:8.0.0-SNAPSHOT works fine.

@barkbay @jsoriano could you please take a look at this, from what I understand the intention was not to switch to BEATS_STRICT_PERMS=false.

[elasticmachine]

Pinging @elastic/integrations (Team:Integrations)

[jsoriano]

@barkbay @jsoriano could you please take a look at this, from what I understand the intention was not to switch to BEATS_STRICT_PERMS=false.

That's right, BEATS_STRICT_PERMS=false shouldn't be neccesary. We will have to find a middle ground so this file can keep these permissions.

[v1v]

IIUC, BEATS_STRICT_PERMS=false should be enough to bypass this issue, but I'm afraid I've got the same error though:

For instance the docker container apm-server failed with logs

You can reproduce it locally if you run the below docker-compose:

• docker-compose.yml

[jsoriano]

It is BEAT_STRICT_PERMS, sorry (without the S in BEAT).

[jsoriano]

Thinking about this, we would have to discuss what to do. Maybe the best idea is to revert #12905 till we find a good solution, so we avoid having to add workarounds in many places. @barkbay wdyt?

[jsoriano]

I have opened two PRs with possible options to fix this:

• #18872 completely reverts #12905, and we will have to think how to support arbitrary ids, without breaking strict permission checks.
• #18873 reverts only the permission changes, but keep the ownership changes. From my local tests with docker this fixes the issue with strict perms, and seems to be enough to be able to run containers with arbitrary user ids.