LuciferYang opened a new issue, #12035: URL: https://github.com/apache/gravitino/issues/12035
### What would you like to be improved? `DataSourceUtils.createDataSource` hands the entire catalog config map to DBCP2's `BasicDataSourceFactory`. Several DBCP2 pool properties cause the factory to load and instantiate an arbitrary class by name via reflection (`Class.forName` + `newInstance`), which is a remote-code-execution vector when a catalog is created/altered: - `connectionFactoryClassName` and `evictionPolicyClassName` — values are class names instantiated at pool init; - `driverClassName` — value is `Class.forName`'d and instantiated by DBCP2's `DriverFactory` (the legitimate driver comes from the `jdbc-driver` property via an explicit setter, so the raw key is never needed); - `initialSize` > 0 — makes the factory eagerly open a connection during `createDataSource`, which triggers the reflective driver load *inside* the factory call, before Gravitino's own `setDriverClassName` override runs. A user reaches these via `gravitino.bypass.<key>=...` (the `gravitino.bypass.` prefix is stripped before the map reaches the datasource). This is the same catalog-creator to server-code-execution threat class already guarded against for unsafe JDBC URL parameters. ### How should we improve? Reject these DBCP2 pool properties from catalog configuration before the config is handed to `BasicDataSourceFactory` (case-insensitive whole-key match), with a clear error. They are never needed for a Gravitino JDBC catalog. -- 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]
