the acl check could not fail, because sudo drops DATA_PATH

Review of 76cd7c2. The ACL finding is right and the fix is correct — verified here that `setfacl -R -P -b`
removes the default entries as well as the access ones, which the man page splits between -b and -k and
does not settle. `acl` is already a core package in setup.sh, so the new hard dependency is real.

But the checker it added cannot fail in the way it is documented to be run.

`assert-uid-free.sh` is invoked as `sudo ./assert-uid-free.sh --check ...`, and sudo's env_reset DROPS
DATA_PATH, so the script falls back to the hardcoded `/home/pastilhas/officerdev/data` — which is not this
machine's data directory and does not exist. Every check in the file is "look for X, report ok when nothing
is found", so a missing root reports clean without looking. Demonstrated: a tree carrying both
`user:65534:rwx` and `default:user:65534:rwx` was reported as `ok  no ACL entries naming uid 65534`.

The ACL check is the one that fails silently and completely, because it is the only one scoped to DATA_PATH
alone — the uid and subuid scans still walk /home and would catch something. So the check just added to
catch the hazard ownership cannot see is the check a wrong DATA_PATH disables.

Fixed by refusing rather than passing:

  require_roots       every search root must exist, or exit 2 naming it and showing the sudo invocation
                      that preserves DATA_PATH
  numeric guard       uid/start/count must be numbers. deprovisionOsAccount logs '<no-subuid-range>' in
                      that position for an account with no /etc/subuid entry, and pasting that log line in
                      — which is exactly how it is meant to be used — made sub_end empty and turned the
                      range scan into a no-op.

The handler's audit line now prints DATA_PATH inside the command it tells the operator to copy, and says
so explicitly when there is no subuid range rather than emitting a command that cannot work.

Verified: bogus root exits 2, non-numeric range exits 2, and the ACL check FAILS on a specimen tree
carrying the entries — the "make it fail before trusting it to pass" step from the spec's own subuid
section, now done for the ACL half too.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

scripts/assert-uid-free.sh

@@ -19,6 +19,35 @@ SEARCH_ROOTS=("$DATA_PATH" /home)
 
 usage() { echo "usage: $0 --capture <user> | --check <user> <uid> <subuid_start> <subuid_count>" >&2; exit 2; }
 
+# ── A search root that does not exist makes this whole script lie ──
+#
+# Every check below is "look for X; report ok when nothing is found", so a root that is missing reports
+# clean without having looked. That is not hypothetical here: this script is documented to run under
+# `sudo`, and sudo's env_reset DROPS DATA_PATH, so the fallback above is what actually gets used. On a
+# host where the fallback is wrong, `--check` scans a directory that does not exist, finds nothing, and
+# prints "CLEAN — uid safe to reissue".
+#
+# The ACL check is the one that fails silently and completely, because it is scoped to DATA_PATH alone.
+# The exact check added to catch the hazard ownership cannot see is the one a missing DATA_PATH disables.
+#
+# So: refuse to run rather than pass vacuously. Same posture the subuid section of the spec argues for.
+require_roots() {
+  local missing=()
+  for root in "${SEARCH_ROOTS[@]}"; do
+    [[ -d "$root" ]] || missing+=("$root")
+  done
+  if (( ${#missing[@]} )); then
+    echo "refusing to check: these search roots do not exist: ${missing[*]}" >&2
+    echo "" >&2
+    echo "DATA_PATH is currently '$DATA_PATH'. sudo strips it from the environment, so pass it through:" >&2
+    echo "  sudo DATA_PATH=/path/to/data $0 --check ..." >&2
+    echo "  (or: sudo -E $0 --check ...)" >&2
+    echo "" >&2
+    echo "Every check here reports 'ok' on finding nothing, so a wrong root reports CLEAN without looking." >&2
+    exit 2
+  fi
+}
+
 if [[ "${1:-}" == "--capture" ]]; then
   user="${2:?user required}"
   uid="$(id -u "$user" 2>/dev/null)" || { echo "no such account: $user" >&2; exit 1; }
@@ -30,6 +59,16 @@ fi
 
 [[ "${1:-}" == "--check" ]] || usage
 user="${2:?}"; uid="${3:?}"; sub_start="${4:?}"; sub_count="${5:?}"
+require_roots
+
+# The range arithmetic has to be numbers. `deprovisionOsAccount` logs '<no-subuid-range>' in this position
+# when the account had no /etc/subuid entry, and pasting that log line straight in — which is exactly how
+# it is meant to be used — would otherwise make sub_end empty and turn the range scan into a no-op.
+[[ "$uid" =~ ^[0-9]+$ && "$sub_start" =~ ^[0-9]+$ && "$sub_count" =~ ^[0-9]+$ ]] || {
+  echo "uid, subuid_start and subuid_count must all be numbers (got: '$uid' '$sub_start' '$sub_count')" >&2
+  echo "an account with no /etc/subuid range has nothing to scan for — verify the uid half by hand" >&2
+  exit 2
+}
 sub_end=$(( sub_start + sub_count - 1 ))
 
 fails=0