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

Provide individual Users and collection Groups for each container #21

Open
jgwehr opened this issue Nov 12, 2021 · 1 comment
Open

Provide individual Users and collection Groups for each container #21

jgwehr opened this issue Nov 12, 2021 · 1 comment
Assignees
Labels
alternative Trying something new docker standards, best practices, tricks enhancement New feature or request security

Comments

@jgwehr
Copy link
Owner

jgwehr commented Nov 12, 2021

https://wiki.servarr.com/docker-guide

Permissions

Ideally, each software runs as its own user and they are all part of a shared group with folder permissions set to 775 (drwxrwxr-x) and files set to 664 (-rw-rw-r--), which is a umask of 002. A sane alternative to this is a single shared user, which would use 755 and 644 which is a umask of 022. You can restrict permissions even more by denying read from “other”, which would be a umask of 007 for a user per daemon or 077 for a single shared user. For a deeper explanation, try the Arch Linux wiki articles about file permissions and attributes and UMASK.
UMASK

Many Docker images accept -e UMASK=002 as an environment variable and some software can be configured with a user, group and umask (NZBGet) or folder/file permission (Sonarr/Radarr), inside the container. This will ensure that files and folders created by one can be read and written by the others. If you are using existing folders and files, you will need to fix their current ownership and permissions too, but going forward they will be correct because you set each software up right.
PUID and PGID

Many Docker images also take a -e PUID=123 and -e PGID=321 that lets you change the UID/GID used inside to that of an account on the outside. If you ever peak in, you’ll find that username is something like abc, nobody or hotio, but because it uses the UID/GID you pass in, on the outside it looks like the expected user. If you’re using storage from another system via NFS or CIFS, it will make your life easier if that system also has matching users and group. Perhaps let one system pick the UID/GIDs, then re-use those on the other system, assuming they don’t conflict.
Example

You run Sonarr using hotio/sonarr, you’ve created a sonarr user with uid 123 and a shared group media with gid 321 which the sonarr user is a member of. You configure the Docker image to run with -e PUID=123 -e PGID=321 -e UMASK=002. Sonarr also lets you configure the user, group as well as folder and file permissions. The previous settings should negate these, but you could configure them if you wanted. An UMASK of 002 results in 775 (drwxrwxr-x) for folders and 664 (-rw-rw-r--) for files. and the user/group are a little tricky because inside the container, they have a different name. Typically they are abc or nobody.

@jgwehr jgwehr self-assigned this Nov 12, 2021
@jgwehr jgwehr added alternative Trying something new enhancement New feature or request security labels Nov 12, 2021
@jgwehr jgwehr added this to the Shareable BitWarden Prototype milestone Nov 12, 2021
@jgwehr
Copy link
Owner Author

jgwehr commented May 6, 2022

Understanding how uid and gid work in Docker containers

https://medium.com/@mccode/understanding-how-uid-and-gid-work-in-docker-containers-c37a01d01cf

@jgwehr jgwehr added the docker standards, best practices, tricks label May 31, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
alternative Trying something new docker standards, best practices, tricks enhancement New feature or request security
Projects
None yet
Development

No branches or pull requests

1 participant