🏯 fix: Guard Worker Credentials From Local Accounts (LibreChat-AI#112)

Everything here defends a threat the merged owner-only fix does not: another
account on the same host. It is separate deliberately, because BYOM's stated
model is a worker on the user's own machine or VM with the sandboxed command as
the adversary, and these checks buy that defence by trading deployment
flexibility for it.

Ownership. Mode bits do not establish trust: a 0600 file owned by another
account is unreadable by others yet fully rewritable by its owner, who then
controls the credential the worker loads - or, for a quarantine marker, can
delete it and let mutations resume. The containing directory is judged the same
way, since an owner lacking write bits today can grant them tomorrow. Root
counts as the trust root. `--default-workspace` is application-owned by
contract, so a pre-existing one under another account is refused too.

Containers. A 0600 file in a directory others can write can be unlinked and
replaced. Publishing goes through `rename`, which replaces the named entry, so
the write path judges the entry's directory; reading follows the link, so both
ends are judged. The sticky bit counts as protection, keeping /tmp-style
parents usable. Only the immediate container is inspected.

Pairing preflight. `pair` redeemed the one-time code before the destination was
known usable, so an unusable path cost the code and left an orphaned remote
pairing. The destination is now validated - rejecting a directory, a
foreign-owned file under a sticky bit that `rename` could not replace, and a
parent that denies the sibling temporary file the publish needs - and then
claimed, so another account cannot take the name while the pairing request is
in flight. The claim records its inode and is released only if the file is
still that inode and still empty, so a concurrent pairing that published a real
identity over the name is never destroyed by another invocation's unwind.

Known gaps, left explicit rather than half-done: only the immediate container
is checked, so a writable ancestor could still rename a private directory out
from under the worker; a bind-mounted destination still fails at `rename` with
EBUSY because every way to detect it either false-positives on btrfs
subvolumes or races; and macOS extended ACLs and Windows ACLs are both outside
what a mode check can see, which needs real ACL inspection on a host that can
validate it.

Author: danny-avila

packages/code/src/cli.ts

@@ -8,6 +8,7 @@ import { pairBridgeWorker } from './pairing.js';
 import { startFileRelay } from './relay.js';
 import { DockerFileRelaySupervisor } from './relay-runtime.js';
 import {
+  assertIdentityPathIsPrivate,
   assertWorkspaceMutationQuarantineOwner,
   clearWorkspaceMutationQuarantine,
   defaultBridgeIdentityPath,
@@ -128,8 +129,14 @@ async function pair(args: string[]): Promise<void> {
     option(args, '--identity') ??
     process.env.LIBRECHAT_CODE_IDENTITY_FILE ??
     defaultBridgeIdentityPath(workerId);
-  const identity = await pairBridgeWorker({ codeApiUrl, workerId, code });
-  await saveBridgeIdentity(identityPath, identity);
+  const reservation = await assertIdentityPathIsPrivate(identityPath);
+  try {
+    const identity = await pairBridgeWorker({ codeApiUrl, workerId, code });
+    await saveBridgeIdentity(identityPath, identity);
+  } catch (error) {
+    await reservation.release();
+    throw error;
+  }
   process.stdout.write(
     `Paired worker ${workerId}. Identity saved to ${identityPath}\n`,
   );