check capabilities instead of UID=0 when mounting tmpfs for secrets
- Dominant language
- Go
- Stars
- 17k
- Forks
- 2.1k
- Avg merge
- 1d 9h
- Merged PRs (30d)
- 105
Description
### Nomad version
0.12 (but checking code appears to be still present in latest versions)
### Operating system and Environment details
docker, linux RHEL7
### Issue
When running from a container that is built without a USER command, the container can run with uid 0 but without root privileges. This causes the raw_exec driver to fail with e.g.
`[ERROR] client.alloc_runner.task_runner: prestart failed: alloc_id=eba12eb6-7b3a-670a-62a0-aeb559c27eea task=temp-chunkserver-task error="prestart hook "task_dir" failed: mount: operation not permitted"
`
The problem seems to be when it tries to create the secrets dir in [fs_linux.go](https://github.com/hashicorp/nomad/blob/85ed8ddd4fc41b371fb4d652bb9149129893ae6d/client/allocdir/fs_linux.go#L45). It assumes that uid 0 will have the ability to perform the mount operation, but this is not true in my case
Could that code do a better test for root perms? Or just try the mount and fail back to creating the dir? Perhaps it should always just create the dir if fs isolation is none?
### Reproduction steps
Due to my locked-down firm environment, I'm not able to freely run docker myself, so not 100% sure on what exact steps are to get a container to run as uid 0 but without root perms.
- build container without USER command in Dockerfile
- run container in non-privileged mode
- run nomad client from inside the container
- observe that client can't launch any tasks with raw_exec
I'm not quite sure what causes the container to be run with uid 0 - it doesn't always seem to be the case (it worked OK in a kubernetes cluster, but not from a gitlab runner).
I realise that not having a USER command in a dockerfile is bad practice. But might be nice if nomad just worked anyway.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reading client/allocdir/fs_linux.go around the tmpfs mount for the secrets directory and trace how raw_exec task setup handles the failure. Reproduce the non-privileged UID 0 environment if possible, then verify that task startup no longer fails when mounting is unavailable and that the intended fallback or capability check is covered by tests.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker, go, linux
- Domain
- backend, devops, operating-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100