HyukjinKwon commented on code in PR #58414:
URL: https://github.com/apache/spark/pull/58414#discussion_r3974251752
##########
sql/catalyst/src/main/scala/org/apache/spark/sql/internal/StaticSQLConf.scala:
##########
@@ -146,6 +146,21 @@ object StaticSQLConf {
.booleanConf
.createWithDefault(true)
+ val HIVE_THRIFT_SERVER_ALLOW_INEFFECTIVE_DOAS =
+ buildStaticConf("spark.sql.hive.thriftServer.allowIneffectiveDoAs")
+ .doc("With hive.server2.enable.doAs=true the Spark Thrift Server
impersonates the " +
+ "connecting user for Hive metastore calls, but it executes queries and
accesses " +
+ "storage as its own service identity (SPARK-5159), so storage-level
permissions are " +
+ "checked against the privileged service principal instead of the
impersonated user. " +
+ "Because that can silently grant users access to data they could not
read with their " +
+ "own credentials, the server refuses to start when
hive.server2.enable.doAs=true and " +
+ "hive.server2.authentication verifies user identities (anything other
than " +
+ "NONE/NOSASL), unless this option is set to true to acknowledge the
limitation.")
+ .version("5.0.0")
+ .withBindingPolicy(ConfigBindingPolicy.NOT_APPLICABLE)
+ .booleanConf
+ .createWithDefault(false)
Review Comment:
Defaulting this to `false` means the Thrift Server *refuses to start* for
any existing `hive.server2.enable.doAs=true` + verifying-auth (Kerberos/LDAP)
deployment once it upgrades to 5.0. The SPARK-5159 rationale is sound, and the
escape hatch + migration-guide entry + the 4.x warn-first #58438 are the right
scaffolding. The open question is whether *refuse-to-start* is the right
default for 5.0: it turns a long-latent, silently-"working" config into an
immediate startup outage on upgrade. If the hard-fail default is intended, it's
worth a prominent release-note callout (beyond the migration guide) given how
many secured HS2 deployments run `doAs=true`; if not, a loud startup warning
that only escalates to a hard error under an explicit opt-in would be less
disruptive while still closing the security gap.
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
