yuqi1129 opened a new issue, #13696: URL: https://github.com/apache/gravitino/issues/13696
### Version 1.3.0; the location validation is also missing on the current branch. ### Describe what's wrong Lance table operations accept caller-provided locations without validating their storage scope before dataset I/O. Registering a table stores the location without checking whether it points to a Lance dataset. The Lance REST drop endpoint then calls `purgeTable`, which passes that location to `Dataset.drop`, including for external tables. This can remove an unrelated directory registered as a table location. Create and schema refresh also use the supplied location directly. The generic catalog's optional `location` property only provides a default path; it does not constrain table-level locations. Expected behavior: - Validate locations against an operator-configured storage scope before dataset I/O. - Reject invalid purge targets before removing table metadata. - Require explicit operator permission to purge external/registered datasets. - Apply consistent validation to create, load, alter, overwrite, and cleanup paths. ### Error message and/or stacktrace The reported register and drop requests both return HTTP 200. No error is returned for a registered location that points to an unrelated directory. ### How to reproduce On a disposable local instance with Lance REST configured: 1. Create a metalake, a `lakehouse-generic` catalog, and a schema. 2. Create a temporary directory containing a marker file and a nested subdirectory. It should not contain a Lance dataset. 3. Register an external Lance table with this directory as its location. 4. Drop the table through the Lance REST endpoint. 5. Observe that the directory and its contents are removed. ### Additional context Relevant code: - REST `registerTable` accepts the supplied location. - `GravitinoLanceTableOperations.dropTable` calls catalog `purgeTable`. - Catalog Lance `purgeTable` deletes external dataset locations through `Dataset.drop`. - Catalog Lance create and schema refresh paths also use locations without storage-scope validation. Filtering `..` alone is insufficient because absolute paths are accepted. Validation should also account for symbolic links, URI authority, and object-store prefixes. -- 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]
