java icon indicating copy to clipboard operation
java copied to clipboard

When BP_JVM_VERSION is 21, the workspace owner has a problem.

Open xeromank opened this issue 2 years ago • 3 comments

Expected Behavior

The owner of the workspace and the sub directories is cnb

Current Behavior

image

The owner of the workspace and the sub directories is 1001. but, if BP_JVM_VERSION is 17, cnb

Steps to Reproduce

bootBuildImage {
    imageName.set(System.getenv("IMAGE"))

    buildpacks.set(listOf(
        "urn:cnb:builder:paketo-buildpacks/java"
    ))

    val profile = "${System.getProperties()["spring.profiles.active"]}"

    environment.set(
        mapOf(
            "BP_JVM_VERSION" to "17",
            "BPE_DELIM_JAVA_TOOL_OPTIONS" to " ",
            "BP_DATADOG_ENABLED" to "true",
            "BPE_SPRING_PROFILES_ACTIVE" to profile,
            "BPE_DD_VERSION" to Constant.VERSION,
            "BPE_LANG" to "en_US.utf8",
        )
    )

    buildCache {
        volume {
            name.set("cache-${rootProject.name}.build")
        }
    }
}

Motivations

xeromank avatar Jan 11 '24 03:01 xeromank

The owner of the workspace and the �sub directories is cnb

The expected behavior is that the uid is 1001 and the gid is 1000 at runtime. This is a change that happened between the Bionic builder and the Jammy builder and it was done to improve the out-of-the-box security posture.

Not a great description, but this is mentioned in the docs here. It is described more in this RFC.

Having said that, I don't fully understand what you're reporting here. I would not expect permissions on /workspace to change just by selecting a different Java version. You might see permission differences if you build from source or if you build from a precompiled JAR file. This is because the /workspace permissions are set initially based on the files from the input permissions (i.e. your source files or the contents of your JAR). I don't think they should be drastically different though.

Anyway, if you could expand on the behavior that you're seeing I can take another look. Thanks

dmikusa avatar Jan 16 '24 14:01 dmikusa

This is because the /workspace permissions are set initially based on the files from the input permissions (i.e. your source files or the contents of your JAR)

I didn't set any permissions separately. Could you tell me how to do it? Or please provide a related link.

xeromank avatar Feb 05 '24 06:02 xeromank

I didn't set any permissions separately. Could you tell me how to do it? Or please provide a related link.

Building locally & pack build -p my-file.jar

If you're on a Linux or MacOS machine, you can just chmod those files to the desired permissions before you build the image. I don't know what you would do on Windows as permissions work differently there, sorry, not a Windows user. Maybe try WSL? or maybe someone else has some ideas.

Building from source (i.e. maven/gradle are run by buildpacks)

You can set permissions on your source code locally. If you have shell scripts that you package with the app or something like that, they should inherit the local permissions. Because the build tool runs in the build container, the files generated by the build tool will have default permissions set by the container. If you need different permissions, then you would need to have Maven or Gradle change the permissions as part of the build.

dmikusa avatar Feb 05 '24 14:02 dmikusa