Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

File permissions for persistent_volume #77

Closed
tstescoTT opened this issue Jan 23, 2025 · 2 comments
Closed

File permissions for persistent_volume #77

tstescoTT opened this issue Jan 23, 2025 · 2 comments
Labels
bug Something isn't working

Comments

@tstescoTT
Copy link
Contributor

tstescoTT commented Jan 23, 2025

Container user must have r/w and host user must have r/w.

Some issues with existing design:

  • user may not have sudo access on host
  • user host account name may be the same as default user (named user) in container
  • using groupadd dockermount and usermod -aG dockermount "$USER" does not immediately take effect, groups are sticky in bash session
  • new directories dont always inherit permissions (e.g. if container makes a directory for output)
@tstescoTT tstescoTT added the bug Something isn't working label Jan 23, 2025
tstescoTT added a commit that referenced this issue Jan 27, 2025
change log:
- add docker-entrypoint.sh that dynamically ensures container has read/write permissions at runtime while using a non-root user to run applications
- update Dockerfile to user docker-entrypoint.sh
- update setup.sh to remove redundant setup_permissions and improve env var readability
@tstescoTT
Copy link
Contributor Author

There were two main options for giving the container read/write access and resolving common issues described above.

option 1: run container with root user

pro:

  • container user can r/w all mounted files

con:

  • application runs as root, security concerns, not best practice
  • new files owned by root, host user cannot write files created by root

option 2: entrypoint.sh script and non-root user for application runtime

  • runs entrypoint script with root
    • give non-root user r/w access to shared files
    • chown + chmod shared files
    • then deescalates to non-root and run application

pro:

  • runs application using non-root user
  • common application pattern
  • using shared group allows host and container user to read/write files

con:

  • runs container as root initially (then descalates for app)
  • need to give each shared directory access by name e.g. for mounting dev files (mitigated but mounting into a single directory CACHE_ROOT).
  • extra steps
  • container setup takes ~30 seconds longer

examples of this pattern with entrypoint.sh script:

tstescoTT added a commit that referenced this issue Jan 28, 2025
change log:
- add docker-entrypoint.sh that dynamically ensures container has read/write permissions at runtime while using a non-root user to run applications
- update Dockerfile to user docker-entrypoint.sh
- update setup.sh to remove redundant setup_permissions and improve env var readability
tstescoTT added a commit that referenced this issue Jan 28, 2025
change log:
- add docker-entrypoint.sh that dynamically ensures container has read/write permissions at runtime while using a non-root user to run applications
- update Dockerfile to user docker-entrypoint.sh
- update setup.sh to remove redundant setup_permissions and improve env var readability
tstescoTT added a commit that referenced this issue Jan 31, 2025
change log:
- add docker-entrypoint.sh that dynamically ensures container has read/write permissions at runtime while using a non-root user to run applications
- update Dockerfile to user docker-entrypoint.sh
- update setup.sh to remove redundant setup_permissions and improve env var readability
@tstescoTT
Copy link
Contributor Author

Addressed in #78

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant