Feat/ocisdev 949/disable direct sharing

[mzner]

Description

Adds two independent, per-deployment config options that let Ops disable direct (user/group/federated) sharing and/or public link sharing:

• OCIS_ENABLE_USER_SHARING (default true) — read by the frontend, graph, sharing, and ocm services. When false:
• Creating new user, group, or federated shares is rejected — enforced both in reva's usershareprovider/ocmshareprovider (the deepest choke point, reached by every client) and in oCIS's own graph service Invite() endpoint (used by the modern web client), for a faster/clearer rejection there.
• The legacy /apps/files_sharing/api/v1/sharees search endpoint returns an empty result instead of searching users/groups.
• The files_sharing.user.enabled and files_sharing.user_enumeration.enabled capabilities report false, so the web UI hides the "share with people" search box.
• Space membership invites and public link sharing are unaffected.
• OCIS_ENABLE_PUBLIC_SHARING (default true) — read by the frontend and sharing services. When false:
• Creating new public links is rejected via reva's publicshareprovider (internal, permission-less links are exempt).
• The files_sharing.public.enabled capability reports false, so the web UI hides public link creation.
• Direct/user sharing is unaffected.

Both settings default to enabled and are fully independent of each other. Requires owncloud/reva#651 (already merged; this PR bumps the vendored dependency to that commit).

Related Issue

• Fixes OCISDEV-949

Motivation and Context

Ops need the ability to lock down sharing per deployment for compliance/security reasons — e.g. disabling all direct user-to-user sharing while still allowing public links (or vice versa), without one setting affecting the other.

How Has This Been Tested?

• test environment: local single-binary oCIS build (ocis server) against the real merged feat: [OCISDEV-949] add option to disable direct (user/group) sharing reva#651 vendor bump, tested manually in the browser at https://localhost:9200
• test case 1: OCIS_ENABLE_USER_SHARING=false — confirmed via /ocs/v2.php/cloud/capabilities that files_sharing.user.enabled and files_sharing.user_enumeration.enabled report false, and manually confirmed the "share with people" search box is hidden in the web UI while public link creation still works
• test case 2: OCIS_ENABLE_PUBLIC_SHARING=false — manually confirmed public link creation is hidden in the web UI while direct user sharing (left at its default) still works
• test case 3: no env vars set — confirmed both features default to enabled
• Full Go test suite (go test ./...) passes with 0 failures; web unit tests (useCanShare, capabilities store) pass

Screenshots (if appropriate):
None — behavior is a hidden/shown UI element; can add before/after screenshots on request.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Technical debt
• Tests only (no source changes)

Checklist:

• Code changes
• Unit tests added
• Acceptance tests added
• Documentation ticket raised:

[kw-security]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[dj4oC]

Adds independent OCIS_ENABLE_USER_SHARING / OCIS_ENABLE_PUBLIC_SHARING config flags (default true) enforced across reva's user/ocm/public share providers and oCIS's graph/frontend/sharing services, so ops can disable direct sharing and/or public link sharing per deployment.

Findings

Security (needs verification, not confirmed exploitable): the new Invite() gate in api_driveitem_permissions.go checks IsSpaceRoot(resourceId) against the raw, caller-supplied resource ID rather than a Stat-verified one — see inline comment. If this can be spoofed on any backend, the whole disable-sharing feature is silently defeated. A01:2021 Broken Access Control — CWE-863.

Stability (concern): usershareprovider.New() — a vendored, exported constructor — gained a 4th parameter. Any un-diffed call site still using the old signature would fail to compile; needs a whole-repo go build ./... confirmation, not just the touched packages. Separately, FileShares.vue's new canShareWithUsers computed collapses "admin disabled sharing instance-wide" and "you personally lack permission" into the same message — minor UX correctness issue, non-blocking.

Performance: No findings — this is a config-gated boolean check at existing handler entry points; one path (sharees.go) got cheaper (skips a gateway RPC) when the flag is off.

Test coverage (blocking): 0%. This PR ships a new security/compliance-relevant permission gate across 5 services with no unit test asserting either flag actually blocks share creation, and no e2e/acceptance test for OCIS_ENABLE_USER_SHARING=false / OCIS_ENABLE_PUBLIC_SHARING=false. The author's "full test suite passes" claim doesn't exercise the new branches — no test in the diff references either flag. Suggested test shape left inline. TODOs found: none. Dependency touched: yes — github.com/owncloud/reva/v2 bumped to track owncloud/reva#651; all 3 Snyk checks (security/license/code) pass on the current head, so no new CVE/license concern from this bump specifically.

Deployment topology check

Compatible — this is a per-service Go config flag read at startup with server-side enforcement in each deployment topology (single binary, docker-compose, k8s); no topology-specific assumptions.

Verdict

Changes requested — not because the feature is wrong, but the access-control bypass question needs a maintainer answer before this ships as a compliance control, the vendor signature change needs a full-repo build check, and the 0% test coverage on new permission-enforcement logic falls well short of the required bar.

🤖 Automated review by Claude Code (security · stability · performance · coverage)

---

Generated by Claude Code

[dj4oC]

@claude please add a playwright test to it

not necessary.