File ownership issues from Docker created file in mounts

[dale-wahl]

If a Docker image creates files to a mounted drive, it does so as the user that was setup in the Docker container. This can create issues when a secondary application/user:group wishes to modify these files. This is a problem with the local endpoints, since remote endpoints download the files from our API endpoint.

I have tried utilizing the --user argument in the Docker run command. That works, but the user must exist in the context of the container/image. Ideally you could do that on image creation (meaning we'd have to rewrite the Dockerfile of the services and ensure they always use a similar user which then we also use on host). You can patch in a user after, but that user may not have access to aspects of the environment set up in the image creation. Lots of failure here. Basically, when I do it, most our existing images fail to run.

One fix that did work would be modifying the files after the fact (e.g., via chown). I have a version of that method, but, annoyingly, I do not know precisely which files were added; I only have the general mount where all files are stored (e.g., the uploads folder UPLOAD_FOLDER_PATH or 4CAT's dataset folder via 4CAT_DATASETS_PATH). I could try time-bounding the chown to effect less files. Generally chowning to the 4CAT user would be fine to do repeatedly if perhaps taxing. But it feels blind and inelegant.

A better fix might be to add acl to our server and let it handle permissions.

• Apply default POSIX ACLs on the host mount points so the target app user/group always has access to newly created files, regardless of the user inside the container. Ownership won’t change; permissions will allow reads/writes.
• Should works even when containers write as root.
• Basically just ensure the user:group of a certain path always gains permissions in addition to the original user:group.

Commands (one-time)

# Install ACL tooling
apt-get install acl

# Replace <UID> (or use g:<GROUP>) with our user/group that must modify files (i.e. 4CAT's user)
# 4CAT datasets
sudo setfacl -R  -m u:<UID>:rwx /path/to/4cat_data
sudo setfacl -dR -m u:<UID>:rwx /path/to/4cat_data
sudo setfacl -dR -m m::rwx    /path/to/4cat_data  # ensure mask permits the additions to actually be able to read/write/execute

# Uploads (currently no problem, but would prevent by granting ownership to DMI service manager user)
sudo setfacl -R  -m u:<UID>:rwx /path/to/dmi_service_manager/uploads
sudo setfacl -dR -m u:<UID>:rwx /path/to/dmi_service_manager/uploads
sudo setfacl -dR -m m::rwx     /path/to/dmi_service_manager/uploads

Alternative (shared group)

• chgrp -R ; chmod -R 2775 to set setgid bit; set default ACL for the group:

sudo chgrp -R <GROUP> /mnt/4TB_fast/4cat-data /opt/dmi_service_manager/uploads
sudo chmod -R 2775    /mnt/4TB_fast/4cat-data /opt/dmi_service_manager/uploads
sudo setfacl -dR -m g:<GROUP>:rwx /mnt/4TB_fast/4cat-data /opt/dmi_service_manager/uploads

Notes

• Default ACLs (-d) ensure new files/dirs inherit access automatically.
• This avoids per-job chown and works across all images without rebuilding.

[dale-wahl]

@stijn-uva bunch of mumbo-jumbo basically saying I think if we install acl (a thing I just learned about), it could solve our "4CAT cannot delete files" issue. Otherwise, maybe a periodic cron job to update the ownership on the 4CAT folder.