We noticed something unexpected (and at first slightly concerning) using the 2.9.0 gateway interface.
On a publisher node, I mkfs a test repo and ls -l /cvmfs :
drwxr-xr-x. 1 almalinux root 6 Mar 1 03:00 repo.dev.computecanada.ca
after starting transaction:
drwxr-xr-x. 1 almalinux almalinux 6 Mar 1 03:02 repo.dev.computecanada.ca
drwx------. 1 almalinux almalinux 6 Mar 1 03:05 repo.dev.computecanada.ca
drwx------. 1 almalinux almalinux 6 Mar 1 03:08 repo.dev.computecanada.ca
drwxr-xr-x. 1 almalinux root 6 Mar 1 03:08 repo.dev.computecanada.ca
So it seems that abort changes the top level dir of a repo to mode 700, and it does not revert back to normal until a successful publish operation.
(It’s also a bit curious that the group changes.) The 700 status persists even after doing
sudo umount /cvmfs/repo.dev.computecanada.ca
sudo cvmfs_server mount -a
However, what is more puzzling is that rebooting reverts it to 755:
$ cvmfs_server list
repo.dev.computecanada.ca (stratum0 / gw - unhealthy)
$ ls -l /cvmfs/
drwxr-xr-x. 2 almalinux root 6 Mar 1 03:00 repo.dev.computecanada.ca
But even then, after sudo cvmfs_server mount -a it still goes back to 700 .
If I rmfs and mkfs again, it reverts to 755, so it must be some local artifact of the state on the publisher node, not stored on the stratum 0.
Clients do honour file modes by default so if the repository somehow got published with mode 700 it would break all access to the repo. Also our publishing process involves copying from a dev repo to a prod repo, so there is a vaguely conceivable possiblity that the dev repo might get aborted, then a copy operation might transfer the mode 0700 to the prod repo, and even if it was only a local artifact on the dev repo it might then result in a chmod encoded in the catalog of the prod repo (not sure of the details on this).
Is the 700 mode after an abort intentional or is this unexpected behaviour?
It seems to me that a repo should return to a normal good state after an abort.
I know that UID/GID ownerships of the top-level repo dir must be encoded in the root catalog , presumably the same is true for the mode of the top dir. However I could not entirely figure out the contents of the root catalog sqlite file.
Hypothetically, if the mode of the top-level repo dir were to change, would I see it here?
sqlite> select mode from catalog where parent_1=‘0’ AND parent_2=‘0’;
Not sure what mode 16877 corresponds to.