Catalog security does not prevent styles from being edited via REST

Description

The order of options involved in saving a style (via rest) can cause issues under certain auth patterns.

Example:
Prerequisites:

-Have 2 workspaces, ws1 and ws2
-Have 2 users, foo, with readwrite access to ws1 but not ws2; and bar, with readwrite access to ws2 but not ws1
-Have the REST /workspaces/*/styles endpoint accessible by ROLE_AUTHENTICATED

Steps to reproduce:

  • foo tries to edit a style in ws2 via REST

Result:

  • A 500 error will be returned, but the contents of the style will still be changed.

The problem can be seen here:

https://github.com/geoserver/geoserver/blob/2.13.0/src/restconfig/src/main/java/org/geoserver/rest/catalog/StyleController.java#L395

The contents of the style resource get changed before the style gets saved to the catalog. Since the Resource store doesn't have any security, this just happens. Then the StyleInfo is saved to the catalog, and there is failure due to security. However, the change has already been made to the resource, and doesn't get reverted.

There seem to be a few options for fixing this.
The most robust would be to have catalog security rules apply to the appropriate objects in the Resource store. This would almost certainly be a substantial api change, and worthy of a GSIP.

The simple solution would just be to attempt a save of the unmodified style immediately after receiving the request.

Environment

None

Assignee

Unassigned

Reporter

Torben Barsballe

Triage

None

Fix versions

None

Affects versions

None

Components

Priority

Medium
Configure