Skip to content

Update Docker executor to use chown, not umask

What does this MR do?

Uses chown, inside a predefined container, updating the build directory's owner to match that of the build container's USER metadata.

Why was this MR needed?

#1736 (closed)

In summary:

  • The predefined container uses a root user. Any predefined step therefore produces files owned by root. These files are then shared with the build container, but are not writable. To solve that problem, a umask 0000 was previously introduced, ensuring that whilst the files are still owned by root, their permissions are 0777 (world writable), so can be written/read by other users.
  • This is now a problem. The ownership and permission modification are unexpected.
  • In this MR, instead of using umask to solve the problem, we instead update just the owner and group (leaving the permissions intact), matching the user and group of the build container. This is only ever performed when the build container's user is a non-root user.

What's the best way to test this MR?

There's two parts to this MR:

  • The introduction of an internal user package that can perform a lookup of the uid and gid of a specified username and groupname provided by the build image. This package has its own tests.
  • The execution of chown upon build container creation. The outcome with/without umask and chown methods is tested in TestDockerRootDirOwner.

What are the relevant issue numbers?

#1736 (closed)

Closes #1736 (closed)

Edited by Arran Walker

Merge request reports