Development record
Open question for the product thinker: should abcd refuse to read its own settings from a ~/.abcd folder that the owner's group can write to? Today it refuses a folder every account can write, and one another account owns, but reads from a group-writable one (0775). Refusing would protect a machine where the group really is shared with other people. It would also newly refuse ordinary installs on Debian and Ubuntu, where the login umask for a user whose group is private to them is 002, so the documented 'mkdir -p ~/.abcd' makes a 0775 folder whose group is only its owner. abcd's own writers create ~/.abcd at 0755 or 0700, so only a folder made by hand is affected. Two readings already disagree: the declaration file itself is refused when group-writable, and the worktree store (implement/loop ensureStore) refuses a group-writable ~/.abcd level. Deferred out of iss-2609290656480443's fix until ruled.
Open question for the product thinker: should abcd refuse to read its own settings from a ~/.abcd folder that the owner's group can write to? Today it refuses a folder every account can write, and one another account owns, but reads from a group-writable one (0775). Refusing would protect a machine where the group really is shared with other people. It would also newly refuse ordinary installs on Debian and Ubuntu, where the login umask for a user whose group is private to them is 002, so the documented 'mkdir -p ~/.abcd' makes a 0775 folder whose group is only its owner. abcd's own writers create ~/.abcd at 0755 or 0700, so only a folder made by hand is affected. Two readings already disagree: the declaration file itself is refused when group-writable, and the worktree store (implement/loop ensureStore) refuses a group-writable ~/.abcd level. Deferred out of iss-2609290656480443's fix until ruled.
Remedy grounds (2026-09-29)
- Why: the three answers CA7 lists, each with its change; the ruling is unanswered and none is picked.
- Sources (consulted 2026-09-29): sshd_config(5) StrictModes checks the modes of the user's files and home directory (https://man.openbsd.org/sshd_config), and upstream OpenSSH refuses any mode with 022 set; Debian's user-group-modes patch admits group-writability 'provided that the group in question contains only the file's owner' (https://sources.debian.org/patches/openssh/1:9.2p1-2+deb12u7/user-group-modes.patch/). The private-group answer is the one the field has shipped for exactly the Debian and Ubuntu umask case this record names.
- Rejected: reading the umask at run time, which says how the folder would be made, not who can write it now.
Frontmatter
| id | iss-2609290703091174 |
|---|---|
| type | issue |
| lifecycle | resolved |
| severity | minor |
.abcd/work/issues/resolved/iss-2609290703091174-open-question-for-the-product-thinker.md
open on GitHub ↗ · commit history ↗
mentions2
- iss-2609290656480443fsutil.ReadHomeDeclaration vets the declaration file's own mode and owner and refuses a symlinked directory on the way to it, but never vets the mode or owner of those directories: a ~/.abcd that every user can write (0777), or one another account owns, holding a 0600 file of the caller's still reads DeclarationOK. Anyone who can write that directory can rename or hard-link a file of the caller's shape in under a declaration's name (rules.json, trusted-roots, path-entry, credentials.json, config.json), so the leaf guards judge a file the caller did not put there. The guard rests on abcd's own writers creating ~/.abcd at 0o755/0o700; a directory made by hand, or re-moded, is never judged.
- iss-2610120640454742The implement loop's worktree store check (ensureStore in internal/core/implement/loop/lane.go) refuses every group-writable level, which is stricter than the product thinker's 2026-10-11 ruling for abcd's own home (admit a group-writable directory when the owner is the group's sole member, fixed for the home by iss-2609290703091174). Found by lane C on 2026-10-12.