(Since 2.7.18) bootBuildImage: /workspace directory is owned by the wrong user id...

[jerchende]

For my Spring Boot Service I build a bootBuildImage with gradle.

With Spring Boot 2.7.18 the /workspace-directory inside the image is owned by User 1001, which is a not existing user id.

‣ docker run -ti --entrypoint /bin/bash <2.7.18 image>
cnb@94f7bdde2982:/workspace$ id
uid=1002(cnb) gid=1000(cnb) groups=1000(cnb)
cnb@94f7bdde2982:/workspace$ ls -la
total 20
drwxr-xr-x 1 1001 cnb  4096 Jan  1  1980 .
drwxr-xr-x 1 root root 4096 Nov 24 10:20 ..
drwxr-xr-x 1 1001 cnb  4096 Jan  1  1980 BOOT-INF
drwxr-xr-x 2 1001 cnb  4096 Jan  1  1980 META-INF
drwxr-xr-x 3 1001 cnb  4096 Jan  1  1980 org

In 2.7.17 the /workspace directory was owned by cnb with user id 1000:

‣ docker run -ti --entrypoint /bin/bash <2.7.17 image>
cnb@c5f7657cab0d:/workspace$ id
uid=1000(cnb) gid=1000(cnb) groups=1000(cnb)
cnb@c5f7657cab0d:/workspace$ ls -la
total 20
drwxr-xr-x 1 cnb  cnb  4096 Jan  1  1980 .
drwxr-xr-x 1 root root 4096 Nov 24 10:21 ..
drwxr-xr-x 1 cnb  cnb  4096 Jan  1  1980 BOOT-INF
drwxr-xr-x 2 cnb  cnb  4096 Jan  1  1980 META-INF
drwxr-xr-x 3 cnb  cnb  4096 Jan  1  1980 org

This causes issues with some file operations, for example logging, because the service is no longer allowed to create files in the /workspace directory.

[wilkinsona]

I believe this is due to #38477. You could explicitly configure the use of the older builder. Before doing so, you should be aware that the Paketo team consider it to be unsafe. This is why we took the unusual step of changing the default in a maintenance release.

I think it's also worth noting that the buildpacks team do not recommend creating files in /workspace (and may have tightened things up in part to enforce this recommendation). I think a better long-term solution would be to stick with the new Jammy-based builder and adapt your application so that it does not write to /workspace.

[ahachmann]

Actually we are currently also facing the problem with the UID, but not in /workspace but with EFS PersistendVolumeClaims in Amazon EKS (Kubernetes). Our EFS files always had the same user id 1000 as the old cnb where running processes. Now that seems to have changed to uid=1002 and access rights are now restricting our services to access those files. Is there a way to configure the UID the process will run with on those images, or what would your suggestion be to solve such issues?

Old Spring-Boot Version: 2.7.9
New Spring-Boot Version: 3.2.5

[wilkinsona]

That's a question for the buildpacks community. AFAIK, it's out of Spring Boot's control.