[dnm] testing if FileMode is affected by umask

[thaJeztah]

I was trying to run a build stage as non-root user, but it uses some cache mounts. So I tried to mount the cache-mount with a specific group (gid), and set permissions to 0775 (instead of the default 0755) to allow the stage to write, but it looks like it still ends up with 0755 permissions.

Most minimal reproducer;

docker build --progress=plain --no-cache -<<'EOF'
# syntax=docker/dockerfile:1

FROM alpine
RUN --mount=type=cache,target=/hello/.cache,mode=0775 ls -la /hello/.cache/

Which shows that the target has 0755 permissions;

#6 [stage-0 1/2] FROM docker.io/library/alpine:latest
#6 DONE 0.0s

#7 [internal] settings cache mount permissions
#7 DONE 0.1s

#8 [stage-0 2/2] RUN --mount=type=cache,target=/hello/.cache,mode=0775  ls -la /hello/.cache/
#8 0.641 total 8
#8 0.641 drwxr-xr-x    2 root     root          4096 May 17 12:04 .
#8 0.641 drwxr-xr-x    3 root     root          4096 May 17 12:04 ..
#8 DONE 0.7s

Looking at that settings cache mount permissions message brings me to this code, which uses llb.Mkdir;

buildkit/frontend/dockerfile/dockerfile2llb/convert_runmount.go

Line 60 in 4b5bf7e

return st.File(llb.Mkdir("/cache", mode, llb.WithUIDGID(uid, gid)), llb.WithCustomName("[internal] settings cache mount permissions"))

My initial assumption is that possibly the given filemode still gets an umask applied, causing the effective permissions to be different.

It's a bit hard to find where the actual Mkdir happens, because that function returns a FileOp (which only contains the options), but looking through tests I see that there's various tests setting a mode, but all of them seem to use a mode that's not affected by umask (assuming default 022 umask); most (if not "all") of them seem to be using (e.g.) 0700 or 0600.

Let's change a test to see if it fails, which may confirm my suspicion.

[thaJeztah]

Hm... right this test doesn't test any file changes, so I'd have to check for some other place to test this.

[tonistiigi]

As discussed in slack, the cause of this seems to be different umask behavior in moby vs buildkitd. buildkitd resets umask in

buildkit/cmd/buildkitd/main_unix.go

Line 20 in eb51e91

syscall.Umask(0)

and doesn't seem to have any leakage issues.

[thaJeztah]

Hm… right. Curious though if we can reset the Umask globally for dockerd; any idea why we never did so? (I know umask has come up a few times, but I think we resolved those on a per-case base by doing a chmod afterwards)