Development record
fsutil.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.
fsutil.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.
Grounds
- pursued: no declaration is read through a directory another account can change except by group-write, which is deferred; a 0777 or foreign-owned ~/.abcd whose 0600 file still reads DeclarationOK would show it wrong
Frontmatter
| id | iss-2609290656480443 |
|---|---|
| type | issue |
| lifecycle | resolved |
| severity | minor |
.abcd/work/issues/resolved/iss-2609290656480443-fsutil-readhomedeclaration-vets-the.md
open on GitHub ↗ · commit history ↗
mentions1
- iss-2609290703091174Open 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.