Perl-Critic
The latest release cannot be extracted with the --same-owner option
Expected behavior:
The release tarball can be extracted with the --same-owner option. This works fine in release PPI-1.278:
wget https://cpan.metacpan.org/authors/id/O/OA/OALDERS/PPI-1.278.tar.gz
gzip -dk PPI-1.278.tar.gz
tar --same-owner -xvf PPI-1.278.tar
However, in release PPI-1.279, the following steps fail:
wget http://www.cpan.org/authors/id/M/MI/MITHALDU/PPI-1.279.tar.gz
gzip -dk PPI-1.279.tar.gz
tar --same-owner -xvf PPI-1.279.tar
Here's a sample of the resulting errors:
tar --same-owner -xvf PPI-1.279.tar
[...]
PPI-1.279/xt/DepReqs.pm
tar: PPI-1.279/xt/DepReqs.pm: Cannot change ownership to uid 197609, gid 197609: Operation not permitted
PPI-1.279/xt/meta.t
tar: PPI-1.279/xt/meta.t: Cannot change ownership to uid 197609, gid 197609: Operation not permitted
PPI-1.279/xt/pmv.t
tar: PPI-1.279/xt/pmv.t: Cannot change ownership to uid 197609, gid 197609: Operation not permitted
PPI-1.279/xt/release/
PPI-1.279/xt/release/changes_has_content.t
tar: PPI-1.279/xt/release/changes_has_content.t: Cannot change ownership to uid 197609, gid 197609: Operation not permitted
tar: PPI-1.279/xt/release: Cannot change ownership to uid 197609, gid 197609: Operation not permitted
tar: PPI-1.279/xt: Cannot change ownership to uid 197609, gid 197609: Operation not permitted
tar: PPI-1.279: Cannot change ownership to uid 197609, gid 197609: Operation not permitted
tar: Exiting with failure status due to previous errors
This leads to problems when pulling certain docker images with podman, as described in https://github.com/linuxserver/docker-smokeping/issues/181.
Hm, seems there are some platform-specific aspects to the release process. I'll look into it tomorrow.
Ok, i looked at it and i need more explanations.
I compared the permissions on the files and the only thing in 1.279 that's missing is some files don't have world-read perms; and the owner names differ.
I don't understand how that leads to tar being unable to change ownership.
I am also baffled as to why you would try to unpack a tarball while retaining an ownership user that doesn't exist on your system.
Sorry for the long delay.
I agree that unpacking a tarball with the original ownership doesn't make a lot of sense. On second thought, I think that the container / podman are primarily responsible for this bug, not PPI.
Nonetheless, I would recommend to use a UID and GID of 1000 for files inside a tarball to reduce error-proneness, if possible. I have attached some technical details below.
As the issue has already been circumvented by the container's maintainer (and might also be fixed with newer versions of podman), I'm now closing this issue.
Thanks for taking the time to review.
The problem described in this issue occurs when extracting the file as Linux's default user (uid=1000), and without elevated privileges. In this scenario, the user only has permission to write files with uid==1000. So, extracting PPI-1.278.tar succeeds, but PPI-1.279.tar fails.
The original problem from https://github.com/linuxserver/docker-smokeping/issues/181 is more complicated. It occurs when running a rootless container with podman, where UIDs from the container (inner) namespace are translated to sub-UIDs in the host's (outer) namespace. Typically, the number of sub-UIDs configured in the outer namespace is limited to e.g. 65536 contiguous sub-UIDs. This means that the highest UID that can be used by a process inside the container is 1000 + 65536 = 66536, which is smaller than 197609 (I don't know why podman tries to spawn a process with UID 197609 though. This might have been bug in podman).