@neggert Adding "/" does will create files "/etc" when exploded using tar -xvf. this layer.tar should work when you extract it at path "/"

But there aren't any other absolute paths in the tar. Notice there is no leading slash for the paths in etc in the output I pasted.

Absolute paths in tars are usually a bad idea, to the point where GNU tar ignores them by default.

Actually, there's a pretty good explanation of the issue in the page I linked.

When tar extracts archive members from an archive, it strips any leading slashes ('/') from the member name. This causes absolute member names in the archive to be treated as relative file names. This allows you to have such members extracted wherever you want, instead of being restricted to extracting the member in the exact directory named in the archive. For example, if the archive member has the name '/etc/passwd', tar will extract it as if the name were really 'etc/passwd'.

File names containing '..' can cause problems when extracting, so tar normally warns you about such files when creating an archive, and rejects attempts to extracts such files.

Other tar programs do not do this. As a result, if you create an archive whose member names start with a slash, they will be difficult for other people with a non-GNU tar program to use. Therefore, GNU tar also strips leading slashes from member names when putting members into the archive. For example, if you ask tar to add the file '/bin/ls' to an archive, it will do so, but the member name will be 'bin/ls'(19).

@tejal29 Do you need anymore information on this? We're forced to revert to Docker because Kaniko-built images don't work in our system.

This appears to be the offending line of code.

I'm on Nic's team now. We're looking at Makisu as an alternative to Kaniko for building containers to be used in the environment in question. It does not build with / in the layers as Kaniko does with the above Dockerfile:

docker run -i --rm --net host -v /var/run/docker.sock:/docker.sock -e DOCKER_HOST=unix:///docker.sock -v /Users/colin/Downloads/test-delete-me:/makisu-context -v /tmp/makisu-storage:/makisu-storage gcr.io/uber-container-tools/makisu:latest build --commit=explicit --modifyfs=true --load --dest /makisu-context/deleteme.tar -t deleteme /makisu-context

$ tar xf deleteme.tar
$ tar --list --verbose --file 25a485*/layer.tar | head
drwxr-xr-x  0 0      0           0 Mar 10 19:00 bin/
-rwxr-xr-x  0 0      0        2345 Jan  5  2019 bin/uncompress
drwxr-xr-x  0 0      0           0 Mar 24 12:17 etc/
drwxr-xr-x  0 0      0           0 Mar 24 12:17 etc/alternatives/
<snip>
$ tar --list --verbose --file e2212*/layer.tar | head
drwxr-xr-x  0 0      0           0 Mar 10 19:00 bin/
-rwxr-xr-x  0 0      0     1168776 Apr 18  2019 bin/bash
-rwxr-xr-x  0 0      0       43744 Feb 28  2019 bin/cat
<snip>
$ find . -iname 'layer.tar' -exec tar --list --verbose --file {}  \; | grep ' /$'
$

We've learned today via uber-archive/makisu#365 that Makisu is deprecated and will no longer be updated after May 4, 2021. That leaves Kaniko as our only currently available option in the long term so we're looking at how we can expedite this change or changing how our internal container runtime handles Kaniko-produced containers with this / entry.