OSSN-0103: Manila resource-lock list trusts a foreign project_id filter

Summary

A non-admin user with a project-scoped token can retrieve another project’s resource lock metadata by supplying a foreign project_id in the GET /resource-locks request. The API only enforces the all-project policy check when the all_projects parameter is present; without it, a user-supplied project_id reaches the database filter unchanged, bypassing project scoping.

Affected Services / Software

manila (>=17.0.0 <20.0.2, >=21.0.0 <21.0.2, >=22.0.0 <22.0.1)

Discussion

Manila’s resource-lock list API accepts an optional project UUID query parameter. The ID is added as a filter and there is no verification whether that the caller is authorized to view locks belonging to that project.

This allows any authenticated user with at least a reader role on any project to retrieve resource lock metadata belonging to other projects. Access rule lock information (deletion and visibility locks) is also exposed, since the same filtering mechanism is reused.

The attack requires that the caller already possesses a valid project-scoped token and knows the target project’s UUID. Project UUIDs are not enumerable, and therefore not guessable, which limits the practical impact.

A fix that adds an extra policy check to validate whether the caller belongs to the supplied project has been merged.

Contacts / References

Author: Carlos da Silva, Red Hat