Jib Core: Cannot set file entry layer ownership using <user name>:<group name> in Linux base image

[bchaoster]

• 0.15.0
• Using linux based image

When using Jib core to add file entries layer, I am trying to specify ownership using String username:groupname. However this doesn't seem to work and always ends up setting layer ownership to root user.

Steps to reproduce:
Try something similar to the following Java code where it is attempting to set ownership of layer using user/group name. If you inspect the result image, you will see that the file 1 belongs to root user.
Jib.from("linux based image with created user user1 and group group1")
.addFileEntriesLayer(FileEntriesLayer.builder()
.addEntry(Paths.get("1"), AbsoluteUnixPath.get("/1"), FilePermissions.fromOctalString("644"),
FileEntriesLayer.DEFAULT_MODIFICATION_TIME, "user1:group1")
.build())
.containerize(Containerizer.to(DockerDaemonImage.named("jib_test:latest"))
.addEventHandler(LogEvent.class,
logEvent -> System.out.println(logEvent.getLevel() + ": " + logEvent.getMessage()))
.setApplicationLayersCache(Paths.get("cache")).setBaseImageLayersCache(Paths.get("cache")));

Why I think this may be happening
Looking at the code in jib-core/src/main/java/com/google/cloud/tools/jib/image/ReproducibleLayerBuilder.java, I see that the tar entry user id and group id is being initialized to 0. When user name and group name are provided, the entry's user and group id still have the value 0. In Linux systems, 0 is the uid and gid of root. I haven't had time to look into apache's tar entry code, but I feel that uid would take precedence over uname.

Please let me know if you need any more information about this or if I am using this incorrectly

[chanseokoh]

Thanks for the feedback. I remember I wasn't really able to figure out if it is actually possible to set ownership purely using non-numeric user and group names. I recall having seen weird behaviors that don't really work. We need to revisit the code, but I recommend using numeric UID and GID, which is working as of now. If string names were supported, it would mean that the UID and GID of files should be dynamically determined. For example, if you create another image based on your image, which updates /etc/passwd, then it would mean different UID and GID for the same files in the new image, which I am not sure makes sense or is even supported by container runtimes. The Linux kernel only sees numbers and never alias names; it's just utilities and programs that merely display the names from /etc/passwd in place of UID and GID. The UID/GID is the ultimate source of truth and the names in /etc/passwd don't matter at all for the kernel.

[bchaoster]

Thanks for quick response! Since it seems like setting ownership isn't possible with non-numeric user and group names for now, I think it would be helpful to update the java comments for
com.google.cloud.tools.jib.api.buildplan.FileEntriesLayer.addEntry( Path sourceFile, AbsoluteUnixPath pathInContainer, FilePermissions permissions, Instant modificationTime, String ownership)
so that it only gives example of using numeric values, or says that only uid/gid is supported. This small change could prevent other's in the future from making a mistake.