Weird layer file permissions
cipherboy opened this issue · 0 comments
TL;DR: Could we get a --chown=0:0 added to the COPY --from=deps of the node_modules?
Ever since dc8b222, it appears the ast-types-flow files have weird permissions in the Docker image. This breaks pulling the image for me on Linux with Podman:
[cipherboy@xps15 59]$ podman pull hashicorp/dev-portal:sha-dc8b222
Resolved "hashicorp/dev-portal" as an alias (/home/cipherboy/.cache/containers/short-name-aliases.conf)
Trying to pull docker.io/hashicorp/dev-portal:sha-dc8b222...
Getting image source signatures
Copying blob 671536a220a1 skipped: already exists
Copying blob c53d85fc1a3d skipped: already exists
Copying blob 371c3ce4a723 [--------------------------------------] 0.0b / 0.0b
Copying blob 985418a47cca [--------------------------------------] 0.0b / 0.0b
Copying blob 43e6571198fa skipped: already exists
Copying blob 767d35d9047f skipped: already exists
Copying blob 213ec9aee27d skipped: already exists
Copying blob 08a19022f78c done
Error: writing blob: adding layer with blob "sha256:08a19022f78c822230a8cfe95eb5eb2c46d0b51ec391c7afd47975545c8292a3": Error processing tar file(exit status 1): potentially insufficient UIDs or GIDs available in user namespace (requested 369884941:1876110778 for /app/website-preview/node_modules/ast-types-flow/README.md): Check /etc/subuid and /etc/subgid: lchown /app/website-preview/node_modules/ast-types-flow/README.md: invalid argument
Investigating with skopeo shows:
$ skopeo copy docker://docker.io/hashicorp/dev-portal:sha-dc8b222 dir:broken
$ cd broken
$ for file in *; do tar -tvf "$file" app/website-preview/node_modules/ast-types-flow/README.md && echo "$file"; done
-rw-r--r-- 369884941/1876110778 2007 2022-11-10 12:13 app/website-preview/node_modules/ast-types-flow/README.md
6aba365745d5618ce883aa1381a1055c511b235c0e262490174ca118de997353 <<--- Top layer
Previously, these files would get the root/root perms:
$ skopeo copy docker://docker.io/hashicorp/dev-portal:sha-f41423a dir:good
$ cd good
$ for file in *; do tar -tvf "$file" app/website-preview/node_modules/ast-types-flow/README.md && echo "$file"; done
-rw-r--r-- root/root 2007 2022-11-08 14:52 app/website-preview/node_modules/ast-types-flow/README.md
5591ae3dfaa5b187aad943e9f3ed1c825a2e876305554c35a9d37aaacdedba56 <<--- Top layer
It appears to come from the upstream ast-types-flow package:
$ curl https://registry.npmjs.org/ast-types-flow/ | jq -r '.versions[."dist-tags".latest].dist.tarball'
https://registry.npmjs.org/ast-types-flow/-/ast-types-flow-0.0.7.tgz
$ wget https://registry.npmjs.org/ast-types-flow/-/ast-types-flow-0.0.7.tgz
$ tar -tvf ast-types-flow-0.0.7.tgz
-rw-r--r-- 369884941/1876110778 749 2015-10-30 02:47 package/package.json
-rw-r--r-- 369884941/1876110778 2007 2015-09-14 00:17 package/README.md
-rw-r--r-- 369884941/1876110778 121821 2015-10-30 01:12 package/lib/types.js
No other package (e.g., ast-types) appears to have this problem with UID/GID being insane, only this one package (both on NPM and on our container builds).
Edit: From below, there do appear to be other slightly weird permissions in the layer, but they don't appear as insane as this package's. Older versions of this package have the same issue, which is rather weird.
Interestingly however, the NPM version appears the same between these two container versions as it comes from the same layer:
[cipherboy@xps15 broken]$ for file in *; do tar -tvf "$file" usr/local/lib/node_modules/npm/package.json && echo "$file"; done
-rw-r--r-- root/root 6721 2022-11-08 14:51 usr/local/lib/node_modules/npm/package.json
7667bd70e4b5ae1383312d072d242581e2d2a22c900c243cfc6c164b28bda433
-rw-r--r-- 0/0 6582 2022-11-04 07:22 usr/local/lib/node_modules/npm/package.json
e91d99bfd247b801afadb780fecc9c83c27af9452aedeb2fea391294f75d22d5
[cipherboy@xps15 good]$ for file in *; do tar -tvf "$file" usr/local/lib/node_modules/npm/package.json && echo "$file"; done
-rw-r--r-- root/root 6721 2022-11-08 14:51 usr/local/lib/node_modules/npm/package.json
7667bd70e4b5ae1383312d072d242581e2d2a22c900c243cfc6c164b28bda433
-rw-r--r-- 0/0 6582 2022-11-04 07:22 usr/local/lib/node_modules/npm/package.json
e91d99bfd247b801afadb780fecc9c83c27af9452aedeb2fea391294f75d22d
so this rules out a NPM version update being the cause of this (the first layer, e91d99bfd has NPM version 8.19.2, which was upgraded to NPM 8.19.3 in the later 7667bd970e).
(note above, that the layer with the bad ast-types-flow is different in the two container versions).
While the layer with the broken packages is the top-most layer, the layer below this is different between each container (but lower layers -- starting with 672ae47d7b -- are the same between these container versions).
This delta layer is the app -- here, the only change is linked above, and package-lock.json doesn't appear to show significant changes in anything interesting. And, outside of the changed permissions, the rest of the delta mostly looks as expected.
However, when we get to the top layer, things get interesting: the contents are roughly the same, but the permissions are all over the place:
[cipherboy@xps15 broken]$ tar --numeric-owner -tvf 6aba* | awk '{print $2}' | sort -u
0/0
1000/10
1000/100
1000/1000
1001/1001
1008339469/1876110778
110779/100
120012366/120012366
1516583083/0
2119470584/2042662593
24561/20
340385/5762
369884941/1876110778
501/0
501/20
501/80
502/0
502/20
503/20
505/0
510/600
591400265/20
65534/65534
655369/89939
697256346/1876110778
718322462/454177323
[cipherboy@xps15 good]$ tar --numeric-owner -tvf 5591ae* | awk '{print $2}' | sort -u
0/0
What went from a simple root/root container layer to a whole host of different UIDs/GIDs! It isn't clear (from what info I have here) why that is, perhaps a Docker version changed under us or something equivalent.
But I believe this should be fixed by adding a --chown=0:0 statement to that line. I'll open a PR. :-D