storeAccess cannot revoke client-granted store owners, revoked user keeps full read/write access and stays listed

[csiocc]

Environment

• admin-api reporting API 1.21.0, backend 1.21.2, DB schema 133 (includes d8557b3 and bb64403,
  verified by observed write mask 0x700)
• gromox backend on the same appliance
• Observed both through grommunio-admin-web and through direct REST calls

Summary

Since d8557b3 / bb64403 ("Fix permission bits for store owner"), the storeAccess endpoints
operate on STOREACCESS = FOLDEROWNER | FOLDERCONTACT | FOLDERVISIBLE (0x700). This works for
grants created through the API itself, but breaks down for store owners granted by the mailbox
owner through a client (grommunio-web / Outlook, "Owner" permission on the top of the store):

1. DELETE /domains/{d}/users/{u}/storeAccess/{username} returns 200 "Success" but the revoked
   user keeps full read/write/delete access to the store root (rights 0x4FB remain).
2. Because foldervisible is part of the remaining rights, GET storeAccess keeps listing the
   user. In admin-web this becomes an endless loop: remove the entry from "Additional store
   owners", save, reload, the entry is back. The grant cannot be removed from the admin side at
   all.
3. GET storeAccess also over-reports in general: any of the three bits matches the filter, so a
   user holding a plain read-only grant (foldervisible + readany) on IPM_SUBTREE is listed as
   an "additional store owner" even though gromox derives store ownership from FOLDEROWNER only.

Steps to reproduce

Mailbox target@example.com (user ID {u}, domain ID {d}), grantee grantee@example.com.

1. As target@example.com in grommunio-web: right-click the top-level store entry → share folder →
   add grantee@example.com with permission profile "Owner".
2. Read the raw ACL row:
   GET /api/v1/system/exmdb/target@example.com/folders/9
   → member grantee@example.com with rights: 2043 (0x7FB). So far so good; the grant is also
   visible in GET storeAccess (this part is an improvement over the pre-bb64403 behaviour).
3. Revoke via API:
   DELETE /api/v1/domains/{d}/users/{u}/storeAccess/grantee@example.com → 200 "Success"
4. Read the ACL row again:
   → member still present with rights: 1275 (0x4FB = readany, create, editowned, deleteowned,
   editany, deleteany, createsubfolder, foldervisible)
5. GET /api/v1/domains/{d}/users/{u}/storeAccess → grantee is still listed.
6. Repeat the DELETE (or PUT with {"usernames": []}): both return success, the row stays at
   0x4FB. Removing the entry in admin-web ("Mailbox permissions" → remove chip → save → reload)
   shows the same loop.

Counter-check: a grant created via POST storeAccess (row = exactly 0x700) is revoked cleanly,
the member row is removed entirely. The problem only manifests when the row carries additional
working bits, which is exactly what every client-side "Owner" grant produces.

Analysis (source reading)

The DELETE handler does remove all of 0x700 (0x7FB → 0xFB). However, gromox normalizes every
written ACL row in permission_adjust (exch/exmdb/folder.cpp): a row containing frightsReadAny
gets frightsVisible added back ("0x1 => 0x401"). The result is 0x4FB. Since
getUserStoreAccess filters on member.rights & Permissions.STOREACCESS, the re-added
foldervisible keeps the user listed, and every further revoke is a net no-op:
remove 0x700 → normalization adds 0x400 back → row unchanged.

So each component behaves as designed, but the composition of admin-api delete mask, gromox
normalization, and the GET filter makes client-granted store owners irrevocable through the
storeAccess API.

Expected behaviour / suggestions

• DELETE storeAccess should actually end store access, either by removing the member row on
  IPM_SUBTREE entirely, or by clearing all rights bits (like the
  DELETE /system/exmdb/{user}/folders/{fid}/permissions endpoint does), or at minimum by
  documenting that residual client-granted rights survive.
• GET storeAccess should list actual store owners. Given that gromox maps FOLDEROWNER on
  IPM_SUBTREE to store ownership, filtering on member.rights & FOLDEROWNER would avoid both the
  loop display and listing read-only grantees as store owners.

Impact

An administrator who revokes an "additional store owner" gets a success response while the revoked
user retains full read/write access to the mailbox top level. The admin UI keeps showing the user
as store owner and offers no working way to remove them. This is security-relevant: the only
complete removal paths are the mailbox owner acting in a client, or the raw
/system/exmdb/.../folders/9/permissions endpoint.

[csiocc]

Thanks for picking this up @r4nc0r . The measurements behind this report were taken on a live store
(gromox 3.10.x, admin-api 1.21 writing 0x700), but nobody has run the patch itself against one
yet, so what follows applies the new masks to the rows we measured on the unpatched build.

Point 3 (over-reporting) is fixed by STOREOWNER_EFFECTIVE: a row carrying only
foldercontact/foldervisible no longer shows up. The admin-web loop from point 2 goes away
with it, since after the revoke the residue row has no folderowner bit and drops out of the
list, so the chip stays gone.

Point 1 is unchanged, as the PR description says. The wider revoke mask (0x2700 instead of
0x700) doesn't change the arithmetic for a client-granted owner: 0x7FB minus 0x2700
leaves 0xFB, gromox's permission_adjust re-adds foldervisible for the read bits, and the
row settles at 0x4FB as before. The revoked user keeps full read/write on the store root.

One consequence of combining the two: that 0x4FB residue is now invisible from the admin
side. Before the patch the admin at least saw an entry they couldn't remove; after it the
revoke looks clean while the working rights stay in place. The only way to spot the leftover
is the raw folder ACL (grommunio-admin exmdb <mailbox> folder permissions 0x9, or
GET /api/v1/system/exmdb/<mailbox>/folders/9). I can see the argument for not silently
dropping rights the endpoint never granted, but in that case the behaviour should be stated
somewhere (endpoint docs or release notes), because a 200 on DELETE now implies more than it
does.

No measurements on the legacy 0x2000 half yet. The instance we measured on 2026-08-31 writes
0x700; another one of ours was still writing 0x2000 on 2026-08-27, so its existing store-owner
grants are presumably in that form and would become the legacy case once it moves to the 0x700
build. We haven't checked those rows against the 1.21 filter yet. The invariant table in the PR
looks consistent with what we measured for the modern rows (0x700 revoked cleanly, 0x7FB case
as described above).

[csiocc]

Follow-up from our integration tests on 2026-09-08, after upgrading the test appliance's admin-api to 1.21. This was an existing client-granted entry carried across the upgrade;

The residual ACL and incorrect owner listing were reproduced:

• After revocation through our API-backed service, the application reported updated. The raw ACL on IPM_SUBTREE (folder 9) still contained 0x04FB: readany,create,editowned,deleteowned,editany,deleteany,createsubfolder,foldervisible.
• folderowner and foldercontact were absent. Webmail displayed the remaining profile as Publishing Editor, while admin-web still listed the grantee as an additional store owner.
• When attempting to add/open the target mailbox in grommunio-web afterwards, the operation failed with: Could not open the shared store. (Insufficient access rights to perform the operation).
• Removing the grantee's remaining folder-permission entry in webmail cleared the direct ACL; the subsequent grommunio-admin exmdb <mailbox> folder permissions 9 <grantee> query returned (no entries).

This adds a qualification to the earlier impact wording: the stored read/write/delete bits are confirmed, but they alone do not prove that the grantee can continue using the mailbox. We did not record a successful client-access baseline before this revoke or a successful read/write operation afterwards. The observed opening attempt was denied; this does not establish the outcome for every folder, session or protocol.

The distinction discussed in #95 still applies: correcting the owner-list filter would stop treating this residue as store ownership, while retaining ordinary client-granted folder permissions. We have not live-tested that patch. Documenting the difference between revoking store ownership and removing a folder-permission entry completely would help make the endpoint's behaviour clear.

[r4nc0r]

@csiocc thanks for the follow-up, and for the correction on the impact — your denied open is consistent with how gromox decides this, and it is worth stating why.

Opening another user's store goes through store_object::check_owner_mode (exch/zcore/store_object.cpp), which requires frightsGromoxStoreOwner from get_mbox_perm. That bit comes from FOLDEROWNER on IPM_SUBTREE, or from a literal 0x2000 written by admin-api up to 1.20. The 0x04FB residue has neither, so it cannot be used to open the mailbox — it is an ordinary folder ACL on IPM_SUBTREE, exactly the Publishing Editor profile webmail showed you. So the residue is a folder permission that outlives the store-owner grant, not retained store access. One caveat if you re-test: check_owner_mode caches a positive answer per session for 60 seconds, so an already-open session can survive a revoke that briefly.

Where this stands on master, after 7deb809:

• point 3, over-reporting, is fixed: listing matches FOLDEROWNER | GROMOXSTOREOWNER, so a row carrying only FOLDERCONTACT/FOLDERVISIBLE is no longer reported as a store owner.
• point 2, the admin-web loop, is fixed for DELETE storeAccess/{username}, which now clears both encodings. It is not fixed for the two bulk paths — PUT storeAccess with the user omitted, and grommunio-admin user <mailbox> storeowner remove — when the grant was written up to 1.20: setFolderMembers revokes by omission with 0x700, which does not touch 0x2000, so the entry stays and comes back on reload. That is storeaccess: clear the legacy owner bit when revoking in bulk #98, one line per path. If you still have the carried-over entry on the test appliance, a bulk revoke there before and after that patch would be a better confirmation than mine: the tables in storeaccess: clear the legacy owner bit when revoking in bulk #98 come from the reimplemented ACL primitives, not from a live store.
• point 1 stands as designed: rights the endpoint never granted are not dropped.
• for the rows themselves, grommunio/gromox@8e0dd961 replaces 0x2000 with 0x100 on folder 9 in a one-time schema upgrade.

On documenting the difference, I agree it is the part that makes the 200 honest. The distinction being: DELETE storeAccess ends store ownership, and it deliberately leaves any folder permission the mailbox owner granted in a client. Those are removed by the mailbox owner in a client, or with grommunio-admin exmdb <mailbox> folder permissions 9, which is also where a residue is visible.