manila — Change history

Change history — manila — branch stable/2026.2

Branch stable/2026.2 @ 4fbc4b4f3688 — range 4d7180f148a6..4fbc4b4f3688 (merge base with origin/master, tag 23.0.0, where stable/2026.2 left the default branch; 3 non-merge commits) — no carry-over target given — analysed on 2026-11-02. Raw facts: [_inventory/history_stable-2026.2.md](_inventory/history_stable-2026.2.md) / .json.

The branch was cut at the 23.0.0 release and has received one functional change since: a security fix backported from master. The two other commits are release-bot maintenance.

3. Fix policy control for public shares — security

• Commit: 4fbc4b4f3688e916428a7d95d10009d414e705ab — review https://review.opendev.org/q/Ie283dce157f9c90f5d2ab38c1e74daa7df3ac118 — bugs 2161412, 2168962 — cherry-pick of d82acf175eec168cef5758632a84dbceac2ac341 (master, 2026-10-19).
• Before: a public share is visible to every project, and share_api.get skipped the share:get policy check for public shares. Handlers that load the share before modifying it relied on that call. As a result, any project could:
  • add or remove access rules on someone else's public share, that is grant itself mount access;
  • update its rules (2.88);
  • create backups or replicas of it;
  • soft-delete or restore it. In addition, the export location metadata endpoints looked the export location up globally by UUID, ignoring the share of the URL. Any user could therefore read or change the metadata of any export location, through any share they could see.
• After:
  • share_api.get(context, share_id, for_modification=False) (manila/share/api.py:2430-2447) still skips the check for reads of public shares. With for_modification=True it always checks share:get against the share, and for a public share it raises PolicyNotAuthorized instead of hiding the share.
  • The modifying callers pass for_modification=True:
    • allow_access / deny_access (manila/api/v2/shares.py:785-841, manila/api/v2/shares.py:931-945);
    • soft_delete / restore (manila/api/v2/shares.py:428-450, manila/api/v2/shares.py:453-477);
    • rule update (manila/api/v2/share_accesses.py:149-175);
    • backup create (manila/api/v2/share_backups.py:145-165);
    • replica create (manila/api/v2/share_replicas.py:200-210).
  • Export location metadata: the writes go through _verify_share(..., for_modification=True) (manila/api/v2/share_export_locations.py:49-56). Every metadata operation passes the URL's share id down to the database lookup, through share_id in _get_resource (manila/api/v2/metadata.py:86-105). The lookup is export_location_get_by_uuid(..., share_id=…) (manila/db/sqlalchemy/api.py:4782-4790).
• What a client now sees, verified by the new scenario public-share-ownership (owner: admin project, other project: alt), [_rewrite/exchanges_stable-2026.2.json](_rewrite/exchanges_stable-2026.2.json): | Request by another project | Status | |---|---| | GET of the public share and of its export locations | 200 (unchanged) | | allow_access, soft_delete, POST /share-replicas, PUT …/export_locations/{id}/metadata on the public share | 403 Policy doesn't allow share:get to be performed. | | the same on a private share | 404 NotFound: Resource could not be found. (unchanged) | | an export location UUID of another share in the URL | 404 Share_export_location not found. | The 403 names share:get, not the operation's own rule: clients that parse the message see a read rule on a write.
• Why: privilege escalation. Any authenticated user could mount, copy (backup, replica) or hide (soft delete) another project's public share (release note releasenotes/notes/bug-2161412-enforce-policy-checks-on-public-shares-6cb60f669bb20f6c.yaml).
• Impact on the specification: 01 § 1.7 (authorisation), § 2.1 (share actions), § 2.2 (access rules) and 02 § 2 describe the patched behaviour, since the analysed commit is this fix. No new error class, no migration, no microversion, no new option, no policy default changed.
• Upgrade / operations: none. Deployers that relied on other projects managing access to a public share, for example a shared "public" share administered by a different project, lose that ability and must use the owner project or an admin.
• Carrying it over: no prerequisites in the range. The commit brings 17 new tests in 7 test modules: manila/tests/share/test_api.py (test_get_public_share_*), plus test_shares, test_share_accesses, test_share_backups, test_share_replicas, test_share_export_locations and test_metadata under manila/tests/api/v2/. It applies cleanly on the 23.0.0 base: the cherry-pick has no conflict marker. It is already on master.
• For the OpenKeel rewrite: implement two read paths, one for display and one for modification. A public share is readable by every project but modifiable only by the projects that share:get admits on its own target. Scope export-location lookups by the URL's share. Reproduce the 403-on-public and 404-on-private asymmetry, because the scenario public-share-ownership checks it.

Maintenance-only changes

Carry-over plan

No target was given. To carry the fix to a fork based on 23.0.0:

git cherry-pick -x 4fbc4b4f3688e916428a7d95d10009d414e705ab   # security: ownership checks on public shares (bugs 2161412, 2168962)

Source: reverse-spec-manila/06-change-history_stable-2026.2.md. The _rewrite/ and _inventory/ files are not published on the site.