feat: Ensure EFS is owned by the posix_user to avoid permission issues

[affelaffen]

Description

When specifying a user for running the container, e.g. using the 100:1000 Atlantis user on the default image, the aws_efs_access_point is correctly configured with said posix_user, but the ownership of the root directory is left as the default root:root. This can result in different permission issues, one of which is described in runatlantis/atlantis#2221. By specifying the creation_info, we ensure that the user provided as the executing posix user also owns the directory. If desired, this change can be put behind a feature variable.

Motivation and Context

The issue described in runatlantis/atlantis#2221 is the primary motivation for this change.

Breaking Changes

No breaking changes as such, but this will force recreation of an existing aws_efs_access_point and thus the aws_ecs_task_definition.

How Has This Been Tested?

• I have updated at least one of the examples/* to demonstrate and validate my change(s)
• I have tested and validated these changes using one or more of the provided examples/* projects
• I have executed pre-commit run -a on my pull request

[jensenbox]

@affelaffen I applied this change locally and rebuilt my ECS cluster, EFS volume and EFS Access point and I am still encountering the unsafe repository is owned by someone else issue.

Any suggestion here?

[affelaffen]

@affelaffen I applied this change locally and rebuilt my ECS cluster, EFS volume and EFS Access point and I am still encountering the unsafe repository is owned by someone else issue.

Any suggestion here?

Do you run the module with user = "100:1000"? This is the atlantis user on the official image.

[jensenbox]

I did - with and without. Each time deleting everything in AWS. I can run it all again tomorrow but I would end up in 1 of 3 possible situations: 1) The original issue - git complaining about an unsafe repo 2) The container would not start because of permission issues 3) The container would start but Atlantis could not run a plan because of permission issues I will have to run it again tomorrow and get more specifics. The way I have worked around the issue is to use ephemeral container storage - not ideal but was the only way to move forward.

…

On Mon, Jun 13, 2022 at 11:26 PM Brian Hansen ***@***.***> wrote: @affelaffen <https://github.com/affelaffen> I applied this change locally and rebuilt my ECS cluster, EFS volume and EFS Access point and I am still encountering the unsafe repository is owned by someone else issue. Any suggestion here? Do you run the module with user = "100:1000"? — Reply to this email directly, view it on GitHub <#287 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABOGUJTLMOED4PGGZUQ2HTVPAQ2DANCNFSM5YTXZYUA> . You are receiving this because you commented.Message ID: ***@***.*** com>

[affelaffen]

Since I am using a slightly modified entrypoint script, I did not experience this issue. I tried with a completely new setup and the default image and also ran into the issue with permissions within the /home/atlantis folder. I modified the aws_efs_access_point path to point directly to the home folder instead, and this seems to have solved the issue.

[userhas404d]

Since I am using a slightly modified entrypoint script, I did not experience this issue. I tried with a completely new setup and the default image and also ran into the issue with permissions within the /home/atlantis folder. I modified the aws_efs_access_point path to point directly to the home folder instead, and this seems to have solved the issue.

@affelaffen confirmed this works - thanks!

[antonbabenko]

This PR is included in version 3.17.0 🎉

[antonbabenko]

Thank you all for the fix and confirmation that it works!

[pauloconnor]

This is a breaking change - if you have been running this previously, and have mounted / as your path, changing it to /home/atlantis will result in losing all your previous checkouts and plans. In order to fix it, you need to create a new /home/atlantis in your existing mount, then copy everything over, ensuring permissions are updated

[github-actions]

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.