Don't let a group's members share its mailboxes on

jcoffey-dev commented

2026-10-05 21:16:03 +00:00

Owner

A group's members reach its mailbox through membership, which counts
as owning the account, so every ACL check was skipped: on a scratch
server a member gave an outsider read access to the group's Inbox with
one Mailbox/set shareWith, with no administrator involved and nothing
audited. Who is in a group is an administrator's decision.

AccessToken::is_group_member_only names that case (in the account
only through a group, without Impersonate). For such a member:

Mailbox/set with a shareWith change, on create or update, is
refused as forbidden;
IMAP SETACL and DELETEACL answer NO [NOPERM];
myRights reports mayShare false, and MYRIGHTS leaves out "a";
every other right stays.

Administrators and the account itself are unchanged. The JMAP ACL
test's group section now checks all three for a member and that the
outsider still has nothing (specs/multi-account.md, MA-D0, G1).

jmap_tests and imap_tests pass (RocksDB). The IMAP refusal has no test
of its own yet; imap_tests passing shows the rest is unchanged.

A group's members reach its mailbox through membership, which counts as owning the account, so every ACL check was skipped: on a scratch server a member gave an outsider read access to the group's Inbox with one Mailbox/set shareWith, with no administrator involved and nothing audited. Who is in a group is an administrator's decision. AccessToken::is_group_member_only names that case (in the account only through a group, without Impersonate). For such a member: - Mailbox/set with a shareWith change, on create or update, is refused as forbidden; - IMAP SETACL and DELETEACL answer NO [NOPERM]; - myRights reports mayShare false, and MYRIGHTS leaves out "a"; every other right stays. Administrators and the account itself are unchanged. The JMAP ACL test's group section now checks all three for a member and that the outsider still has nothing (specs/multi-account.md, MA-D0, G1). jmap_tests and imap_tests pass (RocksDB). The IMAP refusal has no test of its own yet; imap_tests passing shows the rest is unchanged.

jcoffey-dev added 1 commit 2026-10-05 21:16:03 +00:00

Don't let a group's members share its mailboxes on

ci / github (pull_request) Skipped

Details

ci / fork-checks (pull_request) Failing after 1m16s

Details

ci / build (pull_request) Canceled after 5m6s

Details

2d8728793c

A group's members reach its mailbox through membership, which counts
as owning the account, so every ACL check was skipped: on a scratch
server a member gave an outsider read access to the group's Inbox with
one Mailbox/set shareWith, with no administrator involved and nothing
audited. Who is in a group is an administrator's decision.

AccessToken::is_group_member_only names that case (in the account
only through a group, without Impersonate). For such a member:

- Mailbox/set with a shareWith change, on create or update, is
  refused as forbidden;
- IMAP SETACL and DELETEACL answer NO [NOPERM];
- myRights reports mayShare false, and MYRIGHTS leaves out "a";
  every other right stays.

Administrators and the account itself are unchanged. The JMAP ACL
test's group section now checks all three for a member and that the
outsider still has nothing (specs/multi-account.md, MA-D0, G1).

jmap_tests and imap_tests pass (RocksDB). The IMAP refusal has no test
of its own yet; imap_tests passing shows the rest is unchanged.

jcoffey-dev added 1 commit 2026-10-05 21:20:44 +00:00

Add the modification notice to the files this changes

ci / github (pull_request) Skipped

Details

ci / fork-checks (pull_request) Successful in 15s

Details

ci / build (pull_request) Successful in 5m38s

Details

github/ci (branch) GitHub Actions

Details

5c1c4c6248

jcoffey-dev merged commit 5f6548bfdd into main