Hello! with z2jh, I hit a snag while trying inject a file using the
“extraFiles” feature shown directly below. Specifically, The file
ending up at the mountPath has a different set of permissions than the
one specified in config.yaml
# config.yaml
singleuser:
extraFiles:
helloworld:
mountPath: /home/jovyan/helloworld
mode: 0
Using the helm upgrade command:
$ helm upgrade --cleanup-on-fail \
--install helm-release-1 jupyterhub/jupyterhub \
--namespace foo \
--create-namespace \
--version=1.2.0 \
--values config.yaml \
--set-file singleuser.extraFiles.helloworld.binaryData=/path/to/a.out.64
The tranfer works great, but the resulting permissions do not match
the ones specified in config.yaml. As seen below in a terminal from
within jupyterhub’s web ui, looking at the helloworld binary.
01 jovyan@host:~$ stat /home/jovyan/helloworld
02
03 File: /home/jovyan/helloworld
04 Size: 16600 Blocks: 40 IO Block: 4096 regular file
05 Device: 100071h/1048689d Inode: 12013364 Links: 1
06 Access: (0440/-r--r-----) Uid: ( 0/ root) Gid: ( 100/ users)
...
Am I missing something, or should line 06 be:
Access: (0000/----------) Uid: ( 0/ root) Gid: ( 100/ users)
Yes, 0000 is weird :), but I was using it as a test case. The permissions
I’m actually trying to set to is 0111.
SO! I decided to do some testing to see how mode numbers in yaml map
to the resulting permissions. Every case shows that the mode number is
being OR’d with 0440
0000 -> 0440
0001 -> 0441
0111 -> 0551
0222 -> 0662
0440 -> 0440
So then, I should ask, is this expected behavior?
more particulars:
- OS:
Google cloud platform
jovyan@host:~$ uname -a
Linux host 5.4.144+ #1 SMP [date] x86_64 x86_64 x86_64 GNU/Linux
- Version(s):
jovyan@host:~$ jupyterhub --version
1.4.2
jovyan@host:~$ python --version
3.9.7