laurentgo commented on code in PR #13879:
URL: https://github.com/apache/iceberg/pull/13879#discussion_r2453208759
##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -3260,6 +3260,71 @@ components:
additionalProperties:
type: string
+ ReadRestrictions:
+ type: object
+ description: >
+ Read restrictions for a table, including projection and row filter
expressions, according to the current schema.
+
+ A client MUST enforce the restrictions defined in this object when
reading data
+ from the table.
+
+ These restrictions apply only to the authenticated principal, user,
or account
Review Comment:
I meant authorization in a broader http sense, not necessarily in terms of
catalog primitives (like grants/policies). What the authorization itself
represents is open for interpretation. User/principals are the obvious ones,
but the environment (for example the engine trustworthiness, or if the client
is from within vs outside) could be part of it. That said, it should be opaque
for the client.
Re ETag, I was not able to find any strong documentation regarding its
support in Iceberg. But ETag is a HTTP concept (not an iceberg one) and the
semantic is about the whole response, not a part of it. If they were some kind
of intermediaries which would basically handle etag and preconditions, this may
cause those intermediaries to return the same response to the wrong audience,
causing security issues
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
