Provider homes are refused on Ubuntu's default umask because ~/.local is group-writable #1236

Suggested labels: bug, stability

Problem

assertSafeDirectory in packages/runtime/src/templates/smithers/agents/provider-home.tsx refuses any provider-home ancestor that is group- or world-writable, unless the directory is sticky:

if (checkPermissions && (stat.mode & 0o022) !== 0 && (stat.mode & 0o1000) === 0)
  throw new Error("provider-home ancestors cannot be group/world writable");

On Ubuntu, and on other distributions that use user private groups, the default umask is 0002. Directories a user creates are therefore 0775 and owned by the user's own private group. On the test host, ~/.local is drwxrwxr-x ubuntu:ubuntu, and the group ubuntu has no other members. As a result, the default provider-home root ~/.local/state/ultrafuzz/provider-homes is refused for every adapter that falls back to it. The agent cannot start, and the campaign fails at its first node that uses such an adapter.

This was found while fixing the umask 0002 forge-guard bug (#1235). CI runners use umask 022, so CI cannot catch it.

Expected

A group-writable ancestor owned by the current user and by a group only that user belongs to grants nobody else write access. It should be accepted. World-writable directories, and group-writable directories whose group has other members, stay refused.

Proposed fix

Before refusing a group-writable ancestor, accept it when all of these hold:

• stat.uid === process.getuid();
• stat.gid === process.getgid();
• that group has no members other than the user in /etc/group (with getent group as a fallback). This is the user-private-group case.

Keep refusing world-writable ancestors without a sticky bit. Add a test that runs under process.umask(0o002) with a private group.