feat(sharings): Add effective access resolver#4857
Merged
taratatach merged 3 commits intoJul 21, 2026
Merged
Conversation
shepilov
reviewed
Jul 21, 2026
| } | ||
| kept := make([]*Sharing, 0, len(sharings)) | ||
| for _, s := range sharings { | ||
| if !s.Active { |
Member
There was a problem hiding this comment.
we should filter here also to only drive shares if we don't care about classical ones, and for classical ones we can have read-only rules
Contributor
Author
There was a problem hiding this comment.
I don't think the current implementation of the resolver makes much sense for drive shares as we built scopes from local vfs docs and their references to sharings while we don't have these docs on drives recipients (and the owner always has full access).
Contributor
Author
There was a problem hiding this comment.
As discussed, we'll need more to check permission for drives recipient members but it's planned in the next issue.
shepilov
reviewed
Jul 21, 2026
shepilov
approved these changes
Jul 21, 2026
shepilov
reviewed
Jul 21, 2026
Nested shared folders need an explicit access mode to distinguish additive inheritance (the default, where parent access applies to children) from the future `limited_access` mode (a restrictive boundary). Add `AccessMode` field on `Sharing` with constants `AccessModeAdditive` and `AccessModeLimitedAccess`. The `EffectiveAccessMode()` method returns `additive` when the field is empty for backwards compatibility with existing sharings.
Add `Sharing.MemberFor(inst)` to resolve the member of a sharing that corresponds to a given instance (the owner entry on the owner's Cozy, the matching recipient entry on a recipient's Cozy), or nil if the instance is not a member. Revoked members are not returned. `checkSharedDrivePermission` (web/sharings/drives.go) replicates similar logic but does not skip revoked members — a potential latent bug that will be addressed separately later.
Add `AccessResolver` to compute the effective access to a file or folder from the additive sharing scopes on its path. `Resolve(targetID)` returns an `*EffectiveAccess` with `CanRead`/`CanWrite` aggregated highest-wins across all active additive scopes where the current instance is a member (via `Sharing.MemberFor`). The target's own share (for shared files) and every shared ancestor directory are considered. `EffectiveAccess.Can(verb)` maps `GET` to `CanRead` and the write verbs to `CanWrite`. `limited_access` scopes are filtered out in v1; `NearestRestrictiveBoundary` and `ChildSharedRootsUnder` are reserved as no-op stubs for that future mode.
taratatach
force-pushed
the
feat/add-effective-access-resolver-for-nested-shared-folders
branch
from
July 21, 2026 14:47
fc236de to
b0d7542
Compare
taratatach
deleted the
feat/add-effective-access-resolver-for-nested-shared-folders
branch
July 21, 2026 15:25
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Add
AccessResolverto compute the effective access to a file orfolder from the additive sharing scopes on its path.
Resolve(targetID)returns an
*EffectiveAccesswithCanRead/CanWriteaggregatedhighest-wins across all active additive scopes where the current
instance is a member (via
Sharing.MemberFor). The target's ownshare (for shared files) and every shared ancestor directory are
considered.
EffectiveAccess.Can(verb)mapsGETtoCanReadandthe write verbs to
CanWrite.limited_accessscopes are filteredout in v1;
NearestRestrictiveBoundaryandChildSharedRootsUnderare reserved as no-op stubs for that future mode.
Fixes #4837