roryqi opened a new issue, #13977: URL: https://github.com/apache/gravitino/issues/13977
### Version main branch and branch-1.3 ### Describe what's wrong 1. `aws-irsa` returns role credentials without a session policy for catalog-level requests, although callers may only have catalog access. 2. `aws-irsa`, `s3-token`, and `oss-token` use user names directly as STS session names; long names or unsupported characters make vending fail. 3. `adls-token` obtains a delegation key from the configured storage account even when a table path names another account, producing an invalid SAS. 4. For `wasb(s)` paths, `adls-token` emits a SAS property under the dfs host, while Iceberg looks it up under the blob host. 5. `oss-token` grants `ListObjects` only for the first path in each bucket when a request contains multiple paths. ### Error message and/or stacktrace Depending on the case, STS rejects the session name, Azure rejects the SAS with a 403, or OSS denies listing under an additional path. The catalog-level IRSA case can return credentials without an error. ### How to reproduce 1. Request catalog credentials with `aws-irsa` configured; inspect the returned credentials and the STS request's absent session policy. 2. Use a long user name or one containing `/` in an STS-backed credential request. 3. Put an ADLS table in a second storage account, or use a `wasbs://` table location. 4. Put an OSS table's `write.data.path` in a second prefix of the same bucket and list that prefix. ### Additional context Expected behavior: Vend only path-scoped IRSA credentials; generate valid, distinguishable STS session names; sign ADLS SAS tokens with the path account's key; use a client-compatible SAS host or reject unsupported schemes clearly; and include every requested OSS list prefix. -- 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]
