However, we found this is likely to cause a number of compatibility issues with existing apps and parts of the ecosystem (see #268).
Whilst we can (and will) adjust our own buildpacks to do the right thing (not write to /layers/ or the app source directory at runtime), it's going to be some time before existing apps/frameworks/... make similar changes. In addition, the failure modes are not easy for users to debug or solve (they will have to know that seeing access denied errors means needing to use chmod to make directories group writeable in an inline buildpack step or similar).
As such, we're deferring making this switch for now, and will revisit in the future (either for Heroku-26, or as an opt-in feature for Heroku-24), when the various third party language ecosystems are more ready for this.
We will still be in compliance with the spec, since it says SHOULD not MUST.
We will also add integration testing to our own CNBs to ensure that they operate correctly in environments that do run split build/run users.
As part of this change, I've also switched the heroku user's ID from 1001 back to 1000, for consistency with the Heroku-20/22 CNB base images.
I've also switched back to the USER <name> syntax instead of USER <id>, since both are permitted by the OCI and CNB specs, and the former is (a) IMO more intuitive (eg for users needing to switch to root and back in their own Dockerfile), (b) matches what Heroku-20/22 do.
The upstream CNB spec recently changed to say that build and run images
SHOULDuse a separate Linux user for each image: https://github.com/buildpacks/rfcs/blob/main/text/0085-run-uid.md https://github.com/buildpacks/spec/blob/platform/0.13/platform.md#run-imageAs such, when adding Heroku-24 we decided to use separate users: https://github.com/heroku/base-images/pull/245#discussion_r1482159182
However, we found this is likely to cause a number of compatibility issues with existing apps and parts of the ecosystem (see #268).
Whilst we can (and will) adjust our own buildpacks to do the right thing (not write to
/layers/or the app source directory at runtime), it's going to be some time before existing apps/frameworks/... make similar changes. In addition, the failure modes are not easy for users to debug or solve (they will have to know that seeing access denied errors means needing to usechmodto make directories group writeable in an inline buildpack step or similar).As such, we're deferring making this switch for now, and will revisit in the future (either for Heroku-26, or as an opt-in feature for Heroku-24), when the various third party language ecosystems are more ready for this.
We will still be in compliance with the spec, since it says
SHOULDnotMUST.We will also add integration testing to our own CNBs to ensure that they operate correctly in environments that do run split build/run users.
As part of this change, I've also switched the
herokuuser's ID from1001back to1000, for consistency with the Heroku-20/22 CNB base images.I've also switched back to the
USER <name>syntax instead ofUSER <id>, since both are permitted by the OCI and CNB specs, and the former is (a) IMO more intuitive (eg for users needing to switch torootand back in their ownDockerfile), (b) matches what Heroku-20/22 do.See also: https://manpages.ubuntu.com/manpages/noble/en/man8/userdel.8.html https://manpages.ubuntu.com/manpages/noble/en/man8/groupadd.8.html
Closes #268. GUS-W-15342842.