System-defined glossary relation types are editable via generic /v1/system/settings PUT (bypasses immutability)

[sonika-shah]

Affected module

openmetadata-service — GlossaryTermRelationSettings (glossary term relation types)

Description

Glossary term relation types are stored in the glossaryTermRelationSettings Settings blob, and the system-seeded ones (relatedTo, synonym, partOf, hasPart, …) carry isSystemDefined: true. These are intended to be immutable — they cannot be edited or deleted.

That immutability is enforced on two of the three write paths, but not the third:

Path	Enforces immutability?
UI (Glossary Term Relations settings page)	✅ edit/delete disabled for system-defined rows
Dedicated API PUT /v1/system/settings/glossaryTermRelationSettings/relationTypes/{name}	✅ throws "System-defined relation types cannot be updated."
Generic API PUT /v1/system/settings (whole glossaryTermRelationSettings blob)	❌ only blocks removing a system-defined type and duplicate names

SystemResource.validateGlossaryTermRelationSettingsUpdate →
GlossaryTermRelationSettingsUtil.validateSystemDefinedRelationTypesPreserved(current, updated) currently checks only that system-defined names are still present. It does not compare fields, so an admin can change any field of a system-defined type (e.g. isTransitive, color, category, description, cardinality) through the generic settings PUT — silently bypassing the guard the UI and the dedicated endpoint enforce.

Steps to reproduce

1. GET /api/v1/system/settings/glossaryTermRelationSettings.
2. In config_value.relationTypes, take a system-defined entry (e.g. partOf) and flip a field — e.g. isTransitive: false → true — keeping isSystemDefined: true.
3. PUT /api/v1/system/settings with the modified blob.

Actual: 200 OK — the system-defined type is modified and persisted.
Expected: rejected, consistent with the UI and the dedicated relationTypes/{name} endpoint.

Proposed fix

Extend validateSystemDefinedRelationTypesPreserved to also reject field modifications to system-defined types (compare normalized current vs incoming, throw when a system-defined entry differs). This closes the gap on the generic settings PUT while leaving custom (non system-defined) types fully editable.

Notes

• Admin-only endpoint, so not a privilege-escalation issue — it's an integrity/consistency gap: system-seeded types should be immutable across all write paths.
• Related area: the same generic-PUT path historically also lacked duplicate-name validation (added later as validateUniqueNames); this is the remaining unguarded invariant on that path.

[sonika-shah]

Scope note: the fix (PR #31865) closes the full invariant on the generic settings PUT — not only editing/removing existing system-defined types, but also creating a new isSystemDefined:true type or promoting a custom type to system-defined (both were previously allowed). Only already-seeded names may carry isSystemDefined:true, and they are immutable.