EFS mount on ECS Fargate - Read/write permissions denied for non root user

Question

I have an ECS Fargate container running a nodejs application with non-root permissions and is also mounted to EFS on /.user_data inside the container.

I followed this AWS tutorial. My setup is almost similar.

Here is the Docker file:

FROM node:12-buster-slim

RUN apt-get update && \ 
    apt-get install -y build-essential \
    wget \
    python3 \
    make \
    gcc \ 
    libc6-dev  \
    git

# delete old user
RUN userdel -r node 

# Run as a non-root user
RUN addgroup "new_user_group" && \
useradd "new_user" --gid "new_user_group" \
--home-dir "/home/new_user"

RUN git clone https://github.com/test-app.git /home/new_user/app

RUN chown -R new_user:new_user_group /home/new_user

RUN mkdir -p /home/new_user/.user_data 
RUN chown -R new_user:new_user_group /home/new_user/.user_data
RUN chmod -R 755 /home/new_user/

WORKDIR /home/new_user/app

RUN npm install

RUN npm run build

EXPOSE 1880

USER new_user

CMD [ "npm", "start" ]

When the Node app tries to write inside /.user_data I am getting read-write permission denied error.

If I run the container as root the app is able to read/write data.

I tried adding an access point to EFS with UID and permissions but that didn't help as well.

Please note: The Dockerfile works fine on my local machine.

Answer 1

Update

Read this blog post - Developers guide to using Amazon EFS with Amazon ECS and AWS Fargate – Part 2 > POSIX permissions

Might be related to the IAM Policy that was assigned to the ECS Task's IAM Role.

"...if the AWS policies do not allow the ClientRootAccess action, your user is going to be squashed to a pre-defined UID:GID that is 65534:65534. From this point on, standard POSIX permissions apply: what this user can do is determined by the POSIX file system permissions. For example, a folder owned by any UID:GID other than 65534:65534 that has 666 (rw for owner and rw for everyone) will allow this reserved user to create a file. However, a folder owned by any UID:GID other than 65534:65534 that has 644 (rw for owner and r for everyone) will NOT allow this squashed user to create a file."

---

Make sure that your root-dir permissions are set to 777. This way any UID can read/write this dir.

To be less permissive, set the root-dir to 755, which is set by default, see the docs. This provides read-write-execute to the root user, read-execute to group and read-execute to all other users.

A user (UID) can't access (read) a sub-directory if there's no read access to its parents (directories).

You can test it easily with Docker, here's a quick example

Create a Dockerfile -

FROM ubuntu:20.04

# Fetch values from ARGs that were declared at the top of this file
ARG APP_NAME
ARG APP_ARTIFACT_DIR
ARG APP_HOME_DIR="/app"
ARG APP_USER_NAME="appuser"
ARG APP_GROUP_ID="appgroup"

# Define workdir
ENV HOME="${APP_HOME_DIR}"
WORKDIR "${HOME}"

RUN apt-get update -y && apt-get install tree

# Define env vars
ENV PATH="${HOME}/.local/bin:${PATH}"

# Run as a non-root user
RUN addgroup "${APP_GROUP_ID}" && \
    useradd "${APP_USER_NAME}" --gid "${APP_GROUP_ID}" --home-dir "${HOME}" && \
    chown -R ${APP_USER_NAME} .

RUN mkdir -p rootdir && \
    mkdir -p rootdir/subdir && \
    touch rootdir/root.file rootdir/subdir/sub.file  && \
    chown -R root:root rootdir && \
    chmod 600 rootdir rootdir/root.file && \
    chmod -R 775 rootdir/subdir

You should play with chmod 600 and chmod -R 775, try different permissions sets such as 777 and 644, and see if it makes sense.

Build an image, run a container, and test the permissions -

docker build boyfromnorth .
docker run --rm -it boyfromnorth bash

root@e0f043d9884c:~$ su appuser
$ ls -la
total 12
drwxr-xr-x 1 appuser root 4096 Jan 30 12:23 .
drwxr-xr-x 1 root    root 4096 Jan 30 12:33 ..
drw------- 3 root    root 4096 Jan 30 12:23 rootdir

$ ls rootdir
ls: cannot open directory 'rootdir': Permission denied