That’s the usual dilemma of what happens if someone misconfigures this or that. In such cases, yes—it becomes a security hole. But keep in mind, a user would need cluster-level privileges to change the blacklist settings (since it can’t be done at the session level). I would rather change settings to a reasonable default here with a proper warning on sensitive UDFs: https://github.com/apache/hive/blob/a5be6cfdffbb65e5cbbb3c71215a7085b888d29a/common/src/java/org/apache/hadoop/hive/conf/HiveConf.java#L4479 An empty string as a default value doesn't show that we discourage people from enabling reflect and similar UDFs by default.
Regards, Laszlo Bodor On Wed, 20 Aug 2025 at 17:35, Riju Trivedi <rtriv...@cloudera.com.invalid> wrote: > Thanks for the thoughtful responses, Laszlo and Okumin! > > I understand the concern about backward compatibility if we continue to > deprecate these classes. Strengthening the safeguard so that creating a > temporary UDF with a blacklisted class *fails* would certainly close this > loophole. > > Although I worry that even if Hive blocks temp UDF creation, the classes > remain available in the JVM. If someone mistakenly removes them from the > blacklist, they instantly become a major security hole. > > I’d like to hear if others also see value in moving toward deprecating and > eventually deleting these classes with a public announcement. > > Thanks, > > Riju > > On Mon, Aug 18, 2025 at 12:23 AM Shohei Okumiya <oku...@apache.org> wrote: > >> Hi, >> >> In my opinion, we should not have had those methods by default, and >> then we can deprecate them with a public announcement. They have >> unusual semantics on access control. Blacklisting them is also an >> option if we choose not to. >> >> Regards, >> Okumin >> >> On Fri, Aug 15, 2025 at 1:47 PM László Bodor <bodorlaszlo0...@gmail.com> >> wrote: >> > >> > Hi Riju! >> > >> > Good catch! >> > >> > I’m afraid we can’t remove classes from the hive-exec JAR as long as >> users are expected to adjust the blacklist configuration and rely on those >> options. So the only viable approach is an alternative safeguard. >> > >> > Given the registry here: >> > >> https://github.com/apache/hive/blob/78db8e93e7e713e0ba7d5dcb9fc7792d12cae38c/ql/src/java/org/apache/hadoop/hive/ql/exec/FunctionRegistry.java#L583 >> > >> > The behavior should be: if “reflect” is blacklisted, then creating a >> UDF with a class (e.g., GenericUDFReflect) that falls under a blacklisted >> UDF should fail with a clear, user-friendly exception. >> > >> > Regards, >> > Laszlo Bodor >> > >> > >> > On Fri, 15 Aug 2025 at 02:54, Riju Trivedi >> <rtriv...@cloudera.com.invalid> wrote: >> >> >> >> Hello Team, >> >> >> >> We have identified a potential security gap in Hive’s handling of >> blacklisted UDFs. While reflect, reflect2, java_method, and in_file are >> blacklisted via the hive.server2.builtin.udf.blacklist property to prevent >> direct invocation, their corresponding classes (e.g., >> org.apache.hadoop.hive.ql.udf.generic.GenericUDFReflect) are still shipped >> in hive-exec.jar. >> >> >> >> This allows a user with the privilege to create temporary UDFs to >> register these classes and execute arbitrary Java code as the Hive service >> user, bypassing the blacklist. >> >> >> >> For example, >> >> >> >> CREATE TEMPORARY FUNCTION my_tempudf AS >> 'org.apache.hadoop.hive.ql.udf.generic.GenericUDFReflect'; >> >> >> >> SELECT my_tempudf("java.lang.Runtime", "exec", "...") >> >> >> >> could grant access to Kerberos tickets or sensitive HDFS data. >> >> >> >> Would like to know your thoughts on whether we should consider >> removing these classes from hive-exec.jar Or implementing an alternative >> safeguard to fully block their use? >> >> >> >> Thanks, >> >> >> >> Riju >> >> >> >> >> >
