Mastern använder samma image som agenten och kör därför som root, trots att den varken har Docker-socketen eller några skrivbara monteringar. Ett säkerhetshål i UI:t, webhooken eller OIDC-flödet ger i dag root i containern. Problemet gäller bara mastern; agenten behöver root för att komma åt Docker-socketen.
Tekniska noteringar
USER i Dockerfile går inte att använda, eftersom samma image också kör agenten, och agenten behöver socketen. I stället sätts user: i deploy/master.stack.yml (och i exempel-compose i README om sådant finns).
/run/secrets/* har läsrättighet för alla som standard. Portarna 8080 och 8090 är över 1024. Ingen skrivbar katalog behövs.
Hake:DOCKER_CONFIG/config.json från docker login har normalt rättigheterna 0600 och ägs av användaren på värden. Antingen sätts user: till den användarens uid:gid, eller så dokumenteras att filen måste vara läsbar för den valda uid:n. main loggar redan registry_credentials med information om filen finns. Det borde också loggas om den går att läsa, så att felet inte bara syns som "lookup failed" i UI:t.
Verifiera att inget i mastern skriver till disk, som temporära filer eller HOME. ggcr läser ~/.docker om DOCKER_CONFIG saknas, och HOME kan då vara /.
Scope
Ingår: stackfilen, README och loggraden. Ingår inte: separata images för master och agent.
## Beskrivning
Mastern använder samma image som agenten och kör därför som root, trots att den varken har Docker-socketen eller några skrivbara monteringar. Ett säkerhetshål i UI:t, webhooken eller OIDC-flödet ger i dag root i containern. Problemet gäller bara mastern; agenten behöver root för att komma åt Docker-socketen.
## Tekniska noteringar
- `USER` i Dockerfile går inte att använda, eftersom samma image också kör agenten, och agenten behöver socketen. I stället sätts `user:` i `deploy/master.stack.yml` (och i exempel-compose i README om sådant finns).
- `/run/secrets/*` har läsrättighet för alla som standard. Portarna 8080 och 8090 är över 1024. Ingen skrivbar katalog behövs.
- **Hake:** `DOCKER_CONFIG/config.json` från `docker login` har normalt rättigheterna `0600` och ägs av användaren på värden. Antingen sätts `user:` till den användarens uid:gid, eller så dokumenteras att filen måste vara läsbar för den valda uid:n. `main` loggar redan `registry_credentials` med information om filen finns. Det borde också loggas om den går att läsa, så att felet inte bara syns som "lookup failed" i UI:t.
- Verifiera att inget i mastern skriver till disk, som temporära filer eller `HOME`. ggcr läser `~/.docker` om `DOCKER_CONFIG` saknas, och `HOME` kan då vara `/`.
## Scope
Ingår: stackfilen, README och loggraden. Ingår inte: separata images för master och agent.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Beskrivning
Mastern använder samma image som agenten och kör därför som root, trots att den varken har Docker-socketen eller några skrivbara monteringar. Ett säkerhetshål i UI:t, webhooken eller OIDC-flödet ger i dag root i containern. Problemet gäller bara mastern; agenten behöver root för att komma åt Docker-socketen.
Tekniska noteringar
USERi Dockerfile går inte att använda, eftersom samma image också kör agenten, och agenten behöver socketen. I stället sättsuser:ideploy/master.stack.yml(och i exempel-compose i README om sådant finns)./run/secrets/*har läsrättighet för alla som standard. Portarna 8080 och 8090 är över 1024. Ingen skrivbar katalog behövs.DOCKER_CONFIG/config.jsonfråndocker loginhar normalt rättigheterna0600och ägs av användaren på värden. Antingen sättsuser:till den användarens uid:gid, eller så dokumenteras att filen måste vara läsbar för den valda uid:n.mainloggar redanregistry_credentialsmed information om filen finns. Det borde också loggas om den går att läsa, så att felet inte bara syns som "lookup failed" i UI:t.HOME. ggcr läser~/.dockeromDOCKER_CONFIGsaknas, ochHOMEkan då vara/.Scope
Ingår: stackfilen, README och loggraden. Ingår inte: separata images för master och agent.