You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Every now and then I get asked why I use the build phase to change permissions. It's a valid question, so I decided to create this discussion, explaining my view and possibly learning better approaches.
The base image of Many Notes is based on Debian, and the user IDs are 33:33. Everything related to the project will be owned by this user and I had 3 options:
The image leaves the build phase as root, and the container executes as root.
The image leaves the build phase as root, and the container executes as non-root after making the necessary permission changes.
The image leaves the build phase as non-root, and the container executes as non-root.
Option 1
This gives no trouble dealing with permissions, but if an attacker exploits a vulnerability in the container, they may gain root access inside the container. If the container isn't properly isolated, this can potentially lead to root access on the host system.
Option 2
This removes the need for the build phase, but changing the permissions will happen every time the container starts. Every single container restart for backups or a system reboot means a longer start.
Option 3
This requires changing permissions during the build phase, but after that the image is ready. If you restart the container every night to perform backups, it's fast to start again.
Conclusion
Every option has pros and cons but I like to follow the Least Privilege Principle, which means processes should run with the minimum privileges needed to do their job. I avoided the first option for security reasons and, in my opinion, option 3 makes the most sense.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
Every now and then I get asked why I use the build phase to change permissions. It's a valid question, so I decided to create this discussion, explaining my view and possibly learning better approaches.
The base image of Many Notes is based on Debian, and the user IDs are 33:33. Everything related to the project will be owned by this user and I had 3 options:
Option 1
This gives no trouble dealing with permissions, but if an attacker exploits a vulnerability in the container, they may gain root access inside the container. If the container isn't properly isolated, this can potentially lead to root access on the host system.
Option 2
This removes the need for the build phase, but changing the permissions will happen every time the container starts. Every single container restart for backups or a system reboot means a longer start.
Option 3
This requires changing permissions during the build phase, but after that the image is ready. If you restart the container every night to perform backups, it's fast to start again.
Conclusion
Every option has pros and cons but I like to follow the Least Privilege Principle, which means processes should run with the minimum privileges needed to do their job. I avoided the first option for security reasons and, in my opinion, option 3 makes the most sense.
Beta Was this translation helpful? Give feedback.
All reactions