shfshihuafeng commented on code in PR #3056: URL: https://github.com/apache/drill/pull/3056#discussion_r3636060770
########## drill-ranger/drill-ranger-plugin/pom.xml: ########## @@ -0,0 +1,270 @@ +<?xml version="1.0" encoding="UTF-8"?> +<!-- + Licensed to the Apache Software Foundation (ASF) under one + or more contributor license agreements. See the NOTICE file + distributed with this work for additional information + regarding copyright ownership. The ASF licenses this file + to you under the Apache License, Version 2.0 (the + "License"); you may not use this file except in compliance + with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. +--> +<project xmlns="http://maven.apache.org/POM/4.0.0"; + xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; + xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd";> + <modelVersion>4.0.0</modelVersion> + + <parent> + <groupId>org.apache.drill</groupId> + <artifactId>drill-ranger-parent</artifactId> + <version>1.23.0-SNAPSHOT</version> + </parent> + + <artifactId>drill-ranger-plugin</artifactId> + <name>Drill : Ranger Drill Authorization Plugin</name> + <description> + Apache Ranger authorization plugin for Apache Drill. + Loaded by the Drillbit at runtime; performs local in-memory policy + evaluation against policies pulled from Ranger Admin. Does NOT connect + to Drill and does NOT depend on drill-jdbc. + </description> + + <properties> + <ranger.version>2.8.0</ranger.version> + <hadoop.version>3.3.4</hadoop.version> + </properties> + + <dependencies> + <!-- Ranger plugin dependencies. + IMPORTANT: All transitive dependencies that conflict with Drill's + versions MUST be excluded here. This jar is loaded by the Drillbit, + so it reuses Drill's netty / slf4j / hadoop / jackson jars. + See parent pom for Drill's versions: + - netty: 4.1.118.Final + - slf4j: 2.0.6 + - logback: 1.5.25 + - hadoop: 3.3.4 + Without these exclusions, Ranger brings older jars that cause: + - NoSuchFieldError: sizeClass (netty version mismatch) + - SLF4J NOP logger (slf4j binding conflict) --> + <dependency> + <groupId>org.apache.ranger</groupId> + <artifactId>ranger-plugins-common</artifactId> + <version>${ranger.version}</version> + <!-- + Scope is "compile" (default): ranger-plugins-common is deployed as + an independent jar into jars/3rdparty/ by the distribution assembly. + The exclusions below strip conflicting transitive deps (old netty, + slf4j, hadoop, jackson, servlet) so only Ranger's own classes ship. + + ranger-plugins-cred is also excluded: it is the root cause of the + netty transitive chain (ranger-plugins-cred -> netty-handler -> + netty-buffer). Drill's authorization code never touches credstore / + SSL, so cred is pure dead weight and its netty pull-in is unwanted. + --> + <exclusions> + <!-- + Exclude sibling ranger libs that are NOT used by the authorization + code path. They are the source of all transitive conflicts: + - ranger-plugins-cred : pulls io.netty:netty-handler et al. + - ranger-plugins-audit : pulls kafka, solrj, hadoop, etc. + The classes we actually need (RangerBasePlugin, policy model, + access request, RangerDefaultAuditHandler) all live in + ranger-plugins-common itself. ranger-plugins-audit is NOT declared + as a dependency: it only contains audit-sink implementations + (Solr/Kafka/HBase/ES) that Drill never uses, and it is not + available from jitpack.io, causing build failures. + --> + <exclusion> + <groupId>org.apache.ranger</groupId> + <artifactId>ranger-plugins-cred</artifactId> + </exclusion> + <exclusion> + <groupId>org.apache.ranger</groupId> + <artifactId>ranger-plugins-audit</artifactId> + </exclusion> + <exclusion> + <groupId>io.netty</groupId> + <artifactId>*</artifactId> + </exclusion> + <exclusion> + <groupId>org.slf4j</groupId> + <artifactId>*</artifactId> + </exclusion> + <exclusion> + <groupId>ch.qos.logback</groupId> + <artifactId>*</artifactId> + </exclusion> + <exclusion> + <groupId>org.apache.logging.log4j</groupId> + <artifactId>*</artifactId> + </exclusion> + <exclusion> + <groupId>log4j</groupId> + <artifactId>log4j</artifactId> + </exclusion> + <exclusion> + <groupId>commons-logging</groupId> + <artifactId>commons-logging</artifactId> + </exclusion> + <exclusion> + <groupId>org.apache.hadoop</groupId> + <artifactId>*</artifactId> + </exclusion> + <exclusion> + <groupId>com.fasterxml.jackson.core</groupId> + <artifactId>*</artifactId> + </exclusion> + <exclusion> + <groupId>com.fasterxml.jackson.dataformat</groupId> + <artifactId>*</artifactId> + </exclusion> + <exclusion> + <groupId>com.fasterxml.jackson.datatype</groupId> + <artifactId>*</artifactId> + </exclusion> + <exclusion> + <groupId>javax.servlet</groupId> + <artifactId>*</artifactId> + </exclusion> + <!-- + NOTE: javax.ws.rs is NOT excluded. Ranger 2.8.0 was compiled + against JAX-RS 2.x (javax.ws.rs.* namespace), while Drill uses + JAX-RS 3.x (jakarta.ws.rs.* namespace). The two namespaces are + disjoint and coexist safely. jersey-core provides the + javax.ws.rs.core.* API classes, so no separate javax.ws.rs-api + declaration is needed. + --> + <exclusion> + <groupId>com.sun.jersey</groupId> + <artifactId>jersey-bundle</artifactId> + </exclusion> + <exclusion> + <groupId>com.sun.jersey</groupId> + <artifactId>jersey-json</artifactId> + </exclusion> + <exclusion> + <groupId>org.ow2.asm</groupId> + <artifactId>*</artifactId> + </exclusion> + </exclusions> + </dependency> + + <!-- + Jersey 1.x fine-grained client modules. Ranger 2.8.0's + RangerAdminRESTClient extends RangerRESTClient which uses + com.sun.jersey.api.client.* (Client, ClientResponse, WebResource, + ClientHandlerException). These modules are used INSTEAD of the + fat jersey-bundle to avoid shipping jersey.repackaged.org.objectweb.asm + (which conflicts with Jersey 3.1.9's repackaged ASM 9.x). + + jersey-core provides javax.ws.rs.core.* (JAX-RS 2.x API) that + Ranger references, so no separate javax.ws.rs-api jar is needed. + --> + <dependency> + <groupId>com.sun.jersey</groupId> + <artifactId>jersey-client</artifactId> + <version>1.19.4</version> Review Comment: Thanks for flagging this issue in the review — it's an important one. Two points in response: Constrained by Ranger 2.8.0 (the highest resolvable release). Ranger 2.8.0's RangerAdminRESTClient / RangerRESTClient hard-code the com.sun.jersey.api.client.* API, so the plugin must ship Jersey 1.x client/core. Ranger 3.x migrated to Jersey 2.x, but Ranger 3.0.0 artifacts cannot be resolved from the configured repositories, so 2.8.0 is effectively the latest release we can consume right now. Upgrading Ranger is the only path to drop Jersey 1.x. Tracked as a follow-up, not blocking this PR. I've left a SECURITY NOTE block in drill-ranger/drill-ranger-plugin/pom.xml marking this for when Ranger is upgraded. Separately, I'll take a closer look at the Ranger source later to see whether there's a way to avoid shipping the Jersey 1.x client classes entirely. Do you have any other suggestions or a better approach in mind? -- 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]
