PMM-15316 Require group r-x on the secrets dir

The setgid check tested the setgid bit and gid 0 but not whether group 0
could reach the directory at all, so a gid-0 mode-2700 /srv/sep passed it
and published four files SEP cannot open. Verified: at 2700 a uid in group
0 gets EACCES on open and on list; group execute alone (2710) opens by
name but still cannot list, so the mask requires r-x rather than x.

Group write stays out of the mask - only the publishing uid writes here,
which the -w test above already answers - so a 2750 directory, which
works, is not rejected along with the broken ones.

Compare the masked mode against $((8#2050)) rather than the 8#2050
literal: test does not arithmetic-expand its operands, so the literal
form makes [ error out, and inside an || list that error reads as a
false condition and disables the check entirely.

Signed-off-by: Yan Orestes <yan.orestes@percona.com>

Author: yyyyyyyan

.env.example

@@ -81,8 +81,9 @@ PMM_PORT_HTTPS=443
 # Rotating PMM_SEP_POSTGRES_PASSWORD takes two restarts: restart PMM to move the database and
 # rewrite the files, then restart the SEP container, which reads them only at process start.
 # Once SEP is actually in use, PMM Server stops rather than degrading SEP alone: a /srv/sep
-# it cannot write to is fatal, and so is one that is not setgid group 0, since the files
-# would otherwise be published in a group SEP cannot read. Neither check applies under
+# it cannot write to is fatal, and so is one that is not setgid group 0 with group r-x,
+# since the files would otherwise be published in a group SEP cannot read, or behind a
+# directory SEP cannot search. Neither check applies under
 # PMM_HA_ENABLE or PMM_DISABLE_BUILTIN_POSTGRES, which ignore PMM_ENABLE_SEP outright and
 # leave no SEP database to hold a password for - so nothing is generated or written at all.
 # Unsetting PMM_ENABLE_SEP removes all four files on the next start; the persisted

build/ansible/roles/sep/files/sep-secrets

@@ -170,14 +170,17 @@ fi
 
 # -w answers whether this uid can create files here, which is not the question SEP cares
 # about: it reads the 0640 files through group 0, and nothing below sets a group, so the
-# files take whatever the directory hands them. A directory that is not setgid group 0
-# therefore publishes a complete, correct set of secrets SEP cannot open - and the failure
-# surfaces on the SEP side as a missing setting rather than here.
+# files take whatever the directory hands them. Handing them the group is half of it -
+# group 0 needs r-x on the directory too, since a 0640 file behind a directory group 0
+# cannot search is as unreachable as one in the wrong group. A directory failing either
+# half publishes a complete, correct set of secrets SEP cannot open - and the failure
+# surfaces on the SEP side as a missing setting rather than here. Group write is not in
+# the mask: only this uid writes here, which -w already answered.
 declare SECRETS_DIR_GID SECRETS_DIR_MODE
 SECRETS_DIR_GID=$(stat -c '%g' "$SECRETS_DIR")
 SECRETS_DIR_MODE=$(stat -c '%a' "$SECRETS_DIR")
-if [ "$SECRETS_DIR_GID" -ne 0 ] || [ $((8#$SECRETS_DIR_MODE & 8#2000)) -eq 0 ]; then
-    echo "FATAL: $SECRETS_DIR is gid $SECRETS_DIR_GID mode $SECRETS_DIR_MODE, not setgid group 0." >&2
+if [ "$SECRETS_DIR_GID" -ne 0 ] || [ $((8#$SECRETS_DIR_MODE & 8#2050)) -ne $((8#2050)) ]; then
+    echo "FATAL: $SECRETS_DIR is gid $SECRETS_DIR_GID mode $SECRETS_DIR_MODE, not setgid group 0 with group r-x." >&2
     echo "Please run 'chgrp 0 $SECRETS_DIR && chmod g+rwxs $SECRETS_DIR' on the volume mounted there and try again." >&2
     exit 1
 fi