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 >> >>
