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
today was security day for me. 😄 I tried to get the rootless container image up and running as secure as possible using the official helm chart. Therefore the full list of securityContext options were uncommented. Despite the database default, no other value of the chart was modified. Unfortunately, the setup doesn't quite work as expected. My results after several hours of experimenting with it:
The option readOnlyRootFilesystem cannot be used at the moment. When using this option, the container will have restricted access to the /tmp directory. Unfortunately this prevents Gitea itself from writing into it as it happens in the code a few times using os.TempDir. One example is the repository setup (https://github.com/go-gitea/gitea/blob/main/modules/repository/init.go#L293). Can we securely change those occurrences to use the GITEA_TEMP environment variable? Since this variable is not always defined (maybe only in the rootless image), the current behavior could be a fallback initial value if not set?
Additionally, would it be OK to change the current value of the GITEA_TEMP environment variable (/tmp/gitea) to e.g. /etc/gitea/temp? This directory can be created and is writeable due to it's parent directory.
I maybe could provide a PR for these changes, but am unsure about my suggestions and would like to have other opinions or solutions.
Happy for your feedback.
PS: There are some modifications necessary in the helm chart so that the rootless image runs with such strict securityContext without throwing errors to the logs. I opened an issue in that repository as well and provide a possible solution in a PR.
The text was updated successfully, but these errors were encountered:
Ok, this is a neat fix for the /tmp related code. I'll try this. Thanks for the hint.
So you say this whole issue can be reduced to just moving the GITEA_TEMP to another location and set the TMPDIR environment variable in both docker images?
Gitea version (or commit ref): 1.14.2-rootless + 1.14.2
Git version: 2.30.2
Operating system: Official container images (alpine linux) in Kubernetes cluster
It doesn't matter if self-created pod or official helm chart
Database (use
[x]
):Can you reproduce the bug at https://try.gitea.io:
Hi,
today was security day for me. 😄 I tried to get the rootless container image up and running as secure as possible using the official helm chart. Therefore the full list of
securityContext
options were uncommented. Despite the database default, no other value of the chart was modified. Unfortunately, the setup doesn't quite work as expected. My results after several hours of experimenting with it:The option
readOnlyRootFilesystem
cannot be used at the moment. When using this option, the container will have restricted access to the/tmp
directory. Unfortunately this prevents Gitea itself from writing into it as it happens in the code a few times usingos.TempDir
. One example is the repository setup (https://github.com/go-gitea/gitea/blob/main/modules/repository/init.go#L293). Can we securely change those occurrences to use the GITEA_TEMP environment variable? Since this variable is not always defined (maybe only in the rootless image), the current behavior could be a fallback initial value if not set?Additionally, would it be OK to change the current value of the
GITEA_TEMP
environment variable (/tmp/gitea
) to e.g./etc/gitea/temp
? This directory can be created and is writeable due to it's parent directory.I maybe could provide a PR for these changes, but am unsure about my suggestions and would like to have other opinions or solutions.
Happy for your feedback.
PS: There are some modifications necessary in the helm chart so that the rootless image runs with such strict
securityContext
without throwing errors to the logs. I opened an issue in that repository as well and provide a possible solution in a PR.The text was updated successfully, but these errors were encountered: