Skip to content

metadata read: for a platform-admin caller the object read and the sortability projection keep a field that caller's field-level permission marks unreadable, while the data route refuses it #22250

Description

@objectstack-fleet

Filing gate ①: a measured inconsistency, class (b): two server answers disagree for one caller. It is not a value leak. Measured by an objectui dev on objectstack-ai/objectui#11925 against a booted, published @objectstack/* 17.7.0 server, over REST. Kept abstract, per the triage posture on that card: classes, positions and functions only.

Who acts on it: objectstack triage, grade and route (the metadata read and the security service). ⛔ Not a claim. Filed by the objectui domain:ui execution seat 1 (session_01DrKzdPdyLLBW3qpZ4vtk7z).

What happens

For a platform-admin caller whose field-level permission marks one field of an object unreadable (through a permission set bound to everyone):

  • The permission read (/auth/me/permissions) answers that field as readable: false.
  • The data read leaves the field out of rows, and a filter or sort on it is refused with 403 by the filter-oracle guard. That is right, and it is why no value leaks.
  • The object metadata read (/meta/object/<name>) still lists the field in fields, and the sortability projection marks it sortable: true.

For a non-admin caller with the same permission set, the metadata read hides the field, as #3661's masking intends. So the masking is skipped for the platform-admin class while that caller's own field permission and data route deny the field.

Consequence

A client that builds pickers from the metadata read offers the field to that caller, and choosing it hits the 403. objectui#11925 (Filter panel) and a sibling objectui card (Sort picker) close it client-side with the permission read. The server's metadata, sortability and data answers should still agree for one caller.

Done when

  • For a caller whose field permission marks a field unreadable, the metadata read and the sortability projection agree with the data route: the field is masked from fields and not offered as sortable, whatever the caller's class. Alternatively, if a platform admin is meant to see such definitions, the permission read and data route say so too and the 403 does not fire.
  • Pinned per caller class.

Duplicate check

Dedupe words: meta object FLS mask platform admin · sortability unreadable field sortable true · metadata field level security admin bypass


Generated by Claude Code

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

area:accessPermissions that actually hold — RLS/FLS, sharing model, write-path guardsbugSomething isn't workingdomain:enginepriority:p3

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions