Description
Describe the problem/challenge you have
The imgpkg push -i option supports being able to create OCI artefact images containing arbitrary files. Thus it can serve as the equivalent of hosting a tarball on a website, but where things are stored as an image on an image registry.
As much as this appeals as a general solution for packaging up arbitrary files for distribution it suffers a problem.
The problem is that when you run imgpkg push the directories/files copied into the image only preserve user permissions and group/other permissions are discarded. As such, when using imgpkg pull to download and unpack the image, directories/files get unpacked with only user permission set. For example:
0 drwx------ 4 graham wheel 128 8 Mar 12:44 .
0 drwx------ 4 graham wheel 128 8 Mar 12:44 ..
8 -rw------- 1 graham wheel 50 1 Jan 1970 Dockerfile
8 -rw------- 1 graham wheel 13 1 Jan 1970 index.html
8 -rwx------ 1 graham wheel 128 1 Jan 1970 script.sh
This is always the case, and is nothing to do with a user using a restrictive umask. In other words this happens even if the user umask is 022, which should preserve group/other permissions for r-x.
An example of where this is problematic is where the image artefact is used to hold source code files that a user downloads and then needs to run a docker build in to create a runnable container image.
The problem in this case is that if files are copied into the container image using COPY in the Dockerfile they are done so with only user file permissions, but in the container image the files would be owned by root. If the container image is then run as non root it can't access the files copied into the container image.
Describe the solution you'd like
Best solution may be to continue only storing the file permissions in the image, but when unpacking copy the user permissions to group/other, but where whether those permissions persist will depend on the users umask.
Using this approach, where a change is only made in imgpkg pull behaviour, any images created with an older imgpkg version would also work the same. So not dependent on what imgpkg push did.
So instead of the above result, if the umask had been 022, you would get:
0 drwxr-xr-x 4 graham wheel 128 8 Mar 12:44 .
0 drwxr-xr-x 4 graham wheel 128 8 Mar 12:44 ..
8 -rw-r--r-- 1 graham wheel 50 1 Jan 1970 Dockerfile
8 -rw-r--r-- 1 graham wheel 13 1 Jan 1970 index.html
8 -rwxr-xr-x 1 graham wheel 128 1 Jan 1970 script.sh
This is how a Git server effectively works when a fresh copy is checked out.
Anything else you would like to add:
If working in a controlled environment where you know what the umask would be, you can work around the issue if for example you know the umask would be 022, by running:
imgpkg pull -i ... -o ...
chmod -R go=u-w ...
This is okay if being done in a script, but if the user is directly running the imgpkg pull command, it is inconvenient to have to tell them to fix up permissions.
Vote on this request
This is an invitation to the community to vote on issues, to help us prioritize our backlog. Use the "smiley face" up to the right of this comment to vote.
👍 "I would like to see this addressed as soon as possible"
👎 "There are other more important things to focus on right now"
We are also happy to receive and review Pull Requests if you want to help work on this issue.