extraFiles, permissions and the curious octal 0440

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
      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
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

jovyan@host:~$ python --version

Ok!, I think I’m all set on this. If anyone is considering spending time to answer this, then please do not on my account, thank you!