provisioning: re-assert the acl mask, last

on a fresh server an Admin granted files, chat and terminal reached none of
them. the grants were right, the linux account existed, the named acl entries
were on the home — and the file browser still raised EACCES.

a posix acl mask is not independent of the mode bits. chmod recomputes it from
the GROUP bits, so a directory closed to 700 gets `mask::---`, which clamps
every named entry to nothing. the platform's grant survived as
`user:pastilhas:rwx #effective:---`: present, correct-looking, and inert. it
reads as a working acl in every place anyone thought to check.

ensureOsUser already knows this and orders itself correctly — chmod, then
setfacl, with a comment saying why. verified that order is right by running
both ways on the affected host: chmod-then-setfacl gives mask::rwx,
setfacl-then-chmod gives mask::---.

what it cannot account for is the steps AFTER it, each of which creates a
directory and then closes it: .ssh at 700 from the key setup, .config and
.local from the claude installer. each inherits the default acl at creation
and clamps its own mask a moment later. the correlation on the live host was
exact — every 770 directory had mask::rwx and every 700 one had mask::---.

so the mask is re-asserted at the very end of provisionOsAccount, recursively,
and nothing else is touched: the named entries were never wrong, and
re-granting them here would hide it if they ever were.

non-fatal if it fails, like every other side effect in that function. but it
is the difference between an account that works and one that only appears to.

repaired on the affected server by hand first, and confirmed: home readable by
the service user, zero `effective:---` entries left under it.

src/servers/os-user.test.ts

@@ -2,7 +2,7 @@ import { describe, expect, test } from 'bun:test';
 import { chmod, mkdir, mkdtemp, stat, writeFile } from 'node:fs/promises';
 import { tmpdir } from 'node:os';
 import { join } from 'node:path';
-import { findReadableSecrets, osUserNameFor, runAsArgv, secureRuntimeSecrets } from './os-user';
+import { findReadableSecrets, osUserNameFor, runAsArgv, secureRuntimeSecrets, maskArgvFor } from './os-user';
 
 // The tests that matter here are the two that prove the MECHANISM rather than the plumbing: that Bun
 // ignores `uid`, and that `setpriv` does not. Everything else in os-user.ts touches the passwd database
@@ -243,3 +243,36 @@ describe('secureRuntimeSecrets', () => {
     expect(await secureRuntimeSecrets(root)).toEqual({ repaired: [], failed: [] });
   });
 });
+
+describe('ACL mask, after everything else', () => {
+  // The regression: a chmod recomputes the ACL mask from the GROUP bits, so a directory closed to 700
+  // after the platform's grant was set ends up `mask::---`, clamping `user:<service>:rwx` to nothing.
+  // The entry is still there and reads as correct; it just does not grant anything.
+  //
+  // This asserts the shape of the repair rather than the filesystem effect — the effect needs root, an
+  // acl-capable filesystem and a second uid, none of which a unit test has. It was verified live on a
+  // real member's home instead (2026-08-19): READABLE afterwards, and zero `effective:---` entries left.
+  test('re-asserts the mask recursively, and touches nothing else', () => {
+    const argv = maskArgvFor('/data/someone@example.com/home');
+
+    expect(argv).toEqual([
+      'sudo',
+      '-n',
+      'setfacl',
+      '-R',
+      '-m',
+      'm::rwx',
+      '-m',
+      'd:m::rwx',
+      '/data/someone@example.com/home',
+    ]);
+
+    // Recursive, because every subdirectory created-then-closed after the original grant has the same
+    // clamped mask — `.ssh`, `.config` and `.local` all did.
+    expect(argv).toContain('-R');
+    // The default mask too, or the next directory the member creates inherits the broken state.
+    expect(argv).toContain('d:m::rwx');
+    // No named entries: those were always right, and re-granting them here would hide it if they were not.
+    expect(argv.some((a: string) => a.startsWith('u:'))).toBe(false);
+  });
+});