Skip to content

[Bug] Docker images not ready for enhanced security-context in runtime environment #15875

Closed
@justusbunsi

Description

@justusbunsi
  • 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]):

    • PostgreSQL
    • MySQL
    • MSSQL
    • SQLite
  • Can you reproduce the bug at https://try.gitea.io:

    • Yes (provide example URL)
    • No

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 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.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions