ch-builder2tar permission denied

[DavidBrayford]

I am having an issue running the ch-builder2tar command :

sudo ch-builder2tar qxcontexts .
[sudo] password for di72giz:
builder: docker
exporting
/X86/bin/ch-builder2tar: line 151: ./qxcontexts.tar: Permission denied

I have sudo access on the system and successfully built the docker image from the dockerfile with the command :
sudo docker build -t image .

Could it be a system setup issue? As I can contact the sysadmin to make changes.

David

[reidpr]

Hello David, thanks for the question.

Charliecloud scripts aren't designed to be run under sudo; if they need sudo, e.g. to run Docker, they add it for the specific commands needed.

I think what is happening here is that the tarball is being exported as root (because of sudo) but then accessed as yourself.

Does it work as ch-builder2tar qxcontents . (without sudo)?

[DavidBrayford]

Thanks Reid,

I tried without sudo and got the following error :

builder: docker exporting adding environment tar: value 3342364 out of uid_t range 0..2097151 tar: Exiting with failure status due to previous errors

[reidpr]

Are you able to export a tarball manually from Docker? The commands would be something like:

$ cid=$(docker create --read-only $image)
$ docker export $cid > $tar
$ docker rm $cid

That said, it seems to be failing when appending the environment file to the tarball. Stand by.

[reidpr]

This makes me suspect your tar doesn't support your UID:

tar: value 3342364 out of uid_t range 0..2097151

Can you try this and copy-paste the transcript here?

$ cd /tmp
$ echo hello > ./hello
$ ls -lhn ./hello
$ tar cf hello.tar ./hello

[DavidBrayford]

di72giz@rome1:/tmp> echo $PATH
/usr/share/Modules/3.2.10:/home/sw/stack/opt/x86_64/environment-modules/4.3.1-gcc-lwxcyge/bin:/home/di72giz/bin:/usr/local/bin:/usr/bin:/bin:/usr/lib/mit/bin:/opt/rocm/bin:/opt/rocm/profiler/bin:/opt/rocm/opencl/bin/x86_64:/opt/rocm/llvm/bin
di72giz@rome1:/tmp> /bin/sh -c 'echo $PATH'
/usr/share/Modules/3.2.10:/home/sw/stack/opt/x86_64/environment-modules/4.3.1-gcc-lwxcyge/bin:/home/di72giz/bin:/usr/local/bin:/usr/bin:/bin:/usr/lib/mit/bin:/opt/rocm/bin:/opt/rocm/profiler/bin:/opt/rocm/opencl/bin/x86_64:/opt/rocm/llvm/bin
di72giz@rome1:/tmp> which tar
/usr/bin/tar
di72giz@rome1:/tmp> /bin/sh -c 'which tar'
/usr/bin/tar

[reidpr]

Thanks. That tells us that the tar(1) the script is using is the same one you get interactively.

With Docker, the way ch-builder2tar works is to export a tarball using Docker, then docker inspect the environment variables, put those in a temporary file, and add that file to the existing tarball using the system tar.

It's possible that the tarball created by Docker triggers the GNU tar bugs referenced above. I would try walking through the commands in ch-builder2tar manually (starting on line 148) and see if you can replicate the failure. Note you will need to translate them a little bit because you are not in the script environment.

I do suspect this is a GNU tar bug, but even if so we can add a FAQ entry explaining the problem.

[DavidBrayford]

Hi Reid,

I was able to successfully create the tar.gz file in /tmp using sudo ch-builder2tar image . I then used chown to change owner from root.

After working with the sysadmin we discovered :

When using ch-builder2tar as a user, the following error is seen :

tar: value 3637383 out of uid_t range 0..2097151

tar: Exiting with failure status due to previous errors

Running as root, the error does not occur. But a user running the command as “sudo ch-builder2tar” has the issue that root cannot write into the user’s NFS-mounted home directory.

The actual error occurs as follows. Using “sudo docker” to export the image and generate the environment file works fine:

di25koy@rome1:/tmp/foo> sudo docker create --read-only qxcontexts_amd

[sudo] password for di25koy:

c3e41760ac415a6e0643629dc33ecea00c0ad18e74a1fc4590a5d95999502750

di25koy@rome1:/tmp/foo> sudo docker export c3e41760ac415a6e0643629dc33ecea00c0ad18e74a1fc4590a5d95999502750 > test.tar

di25koy@rome1:/tmp/foo> sudo docker inspect qxcontexts_amd --format='{{range .Config.Env}}{{println .}}{{end}}' > tempfile

di25koy@rome1:/tmp/foo> l

total 815196

drwxr-xr-x 2 di25koy pr28fa 38 Jul 27 14:56 ./

drwxrwxrwt 666 root root 61440 Jul 27 14:54 ../

-rw-r--r-- 1 di25koy pr28fa 215 Jul 27 14:56 tempfile

-rw-r--r-- 1 di25koy pr28fa 834657280 Jul 27 14:55 test.tar

However, the tar operation fails with the aforementioned error:

di25koy@rome1:/tmp/foo> tar rf test.tar -b1 -P --xform="s|tempfile|ch/environment|" tempfile

tar: value 3637383 out of uid_t range 0..2097151

tar: Exiting with failure status due to previous errors

di25koy@rome1:/tmp/foo>

But if the environment file belongs to the root user, then the tar succeeds!

di25koy@rome1:/tmp/foo> sudo chown root.root tempfile

di25koy@rome1:/tmp/foo> tar rf test.tar -b1 -P --xform="s|tempfile|ch/environment|" tempfile

di25koy@rome1:/tmp/foo>

This is on sles15sp1, with sw versions tar-1.30-3.3.2.x86_64 and docker-19.03.11_ce-6.34.2.x86_64.

[reidpr]

OK, thanks. It must be a GNU tar bug. The ownership of the file must somehow trigger a different code path.

If you build an upstream tar 1.34 and re-try the above, does the problem still occur?

[DavidBrayford]

No difference :
tar-1.34/src/tar rf test.tar -b1 -P --xform="s|tempfile|ch/environment|" tempfile
tar-1.34/src/tar: value 3637383 out of uid_t range 0..2097151
tar-1.34/src/tar: Exiting with failure status due to previous errors`