rdblue commented on issue #16468: URL: https://github.com/apache/iceberg/issues/16468#issuecomment-4503395353
If I understand correctly, an attacker can create a table and specify its `connectionId`. This is assumed to be a `connectionId` that the attacker cannot use. There is a second user that has access to use that `connectionId`. The second user will use the `connectionId` for the attacker's table. I see two issues with this vector. First, the attacker isn't getting the user with access to the `connectionId` to do anything specific, other than use a resource the user has access to. I don't think that it matters that the user may have access to the `connectionId` for a different purpose. The user has access to it. Second, it isn't clear how the attacker would be able to successfully create a table with a `connectionId` that they do not have access to. Wouldn't the table creation fail? Maybe the attacker could create the table with a different one and then update the value to the new `connectionId` and rely on the initial one begin used for the update? We could probably check that the `connectionId` used to create or update the table is the one that is in the update or create request. But nothing stops an attacker from going directly to the API and not using the client. That means this has to be enforced by the catalog service. I'm going to close this one. -- 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]
