questions about uid change between jammy and bionic stack

[zhoufenqin]

In bionic stack, the uid is the same between build and runtime phases,
But in jammy stack, the uid in build phase is 1001, but in the runtime phase is 1002.

When upgrading bionic stack to jammy stack, it may need to so some code change, like if we have some logic that copy/write files in /workspace dir, it will throw exceptions.

What's the reason to change the uid, and are there any guide to migrate bionic stack to jammy stack smoothly? I think there are other changes too.

[dmikusa]

What's the reason to change the uid,

Security. We have made changes such that the build uid and run uid are different so that at runtime, what you can actually write to is limited.

are there any guide to migrate bionic stack to jammy stack smoothly?

If you have an application that writes to the local file system...

• It's usually going to be writing temporary files because the file system is ephemeral, so write temporary files to /tmp. The /tmp directory is guaranteed to allow the runtime user to write files there. Most language runtimes should detect this and write temporary files to the correct location automatically.
• If you are writing non-temporary files, then mount a volume into the container and write to the volume mount. Since you are mounting the volume you can control the permissions and allow your app to write there.
• If neither of these work, you can have your runtime override the user that runs the container and change the uid to 1001 so that it matches the build uid/user. Ex: docker run --user 1001. You can do the same with K8s in your pod spec.
• While it is not ready yet, we are also working on a chmod buildpack, which will allow you to alter the permissions on files at build time. There is an RFC open discussing this at the moment. I will say that this is probably not the tool you want, it's more of a last resort and extreme special case tool.

I think there are other changes too.

I'm not aware of any other changes that we made, but I suspect someone on the @paketo-buildpacks/builders-maintainers or @paketo-buildpacks/stacks-maintainers can confirm.

You would also want to just watch out for any changes in Ubuntu from Bionic to Jammy that might affect your application. The impact of this will vary depending on your language runtime.

[robdimsdale]

Yup, the other main gotcha is that there are various ABI-incompatible changes between Ubuntu 18.04 / Bionic and 22.04 / Jammy - e.g libssl1 vs libssl3. This would generally only impact users who have hard-coded dependencies on some specific package version, which is uncommon, but worth being aware of.

[zhoufenqin]

Hi @dmikusa
For the security reason, can you give more details about the security? which kind of security do you consider? Like prevent customers from injecting code so as to destroy the built files or some other reasons

Our customers are trying to migrate Bionic to Jammy OS, they also care about the security

[dmikusa]

For the security reason, can you give more details about the security? which kind of security do you consider? Like prevent customers from injecting code so as to destroy the built files or some other reasons

Yes, that's the gist of it. If the buildpacks run as a different user then the files that they install cannot be tampered with by the application code. This prevents a variety of things from happening, not all strictly "security" but some just bad practices or hacks that devs might do. This is often something that platform operators care most about.

Probably more security-related is that it helps to control the damage if someone were to hack your application. They are contained more because they can't write anywhere (except /tmp) or overwrite any of your application files or language runtime files.

There are also some runtimes, I think OpenShift, which generate random uids at runtime, so this also helps to make sure apps will work fine on platforms like that too.

[showpune]

Hi @dmikusa ,

I use the latest builder paketobuildpacks/builder to build the image and find the layer and workspace folder owner is still 1000, is there any gap?

[dmikusa]

I'm not sure why you'd see that. I did a quick build of one of the sample apps, and it is showing what I'd expect (1001 uid, 1000 gid).

Did you try a fresh build? Either build with a different name or add the --clear-cache argument to pack build. That should delete any caching. If you were previously building with an older builder, I'd start fresh just to make sure nothing from that older builder is carrying over.

Other than that. I'm not sure. The uid/gid stuff is part of the lifecycle, so my understanding is that it should just happen like that.