The script imported DATA_PATH and USER_DIRS from data-path.ts and then
reimplemented the mkdir loop without the chmod that module's own
provisionUserDirs applies — 711 on the account root, 700 on each subdir. A
hand-provisioned account would have come out 755 at the default umask, where a
UI-provisioned one is closed. Its header comment warned about exactly this
drift while being an instance of it.
Nothing was ever created that way here: every account on this box was made by
the create-account handler and is correctly 711/700. This is a latent
divergence between two paths that claim to produce identical accounts, not
damage to repair.
Calls provisionUserDirs(email) instead. Two consequences worth naming:
re-running now re-asserts modes on existing directories, so it is also the
repair; and DRY_RUN skips the call outright rather than gaining a dry-run mode
in the real provisioning path to serve a script.
Verified: dry run creates nothing, a fresh root comes out 711/700, and a
directory chmod'd to 755 is restored on the next run.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
pastilhasandClaude Opus 5
c4b262dc51