Does HDFS enforce authorization checks when dfs.permissions.enabled is false on a Kerberized cluster?

Question

We are evaluating a multi-tenant HDFS deployment where Kerberos authentication is required for all client connections, but the cluster administrator is considering setting dfs.permissions.enabled to false to simplify namespace management. The concern is whether disabling the POSIX-style permission model removes all authorization barriers, effectively allowing any authenticated principal to read or write any path, or whether other controls such as ACLs or block-level tokens still constrain access. This behavior may vary by Hadoop release and by whether the NameNode treats the setting as a global toggle for the permission checker.

Can the HDFS NameNode still enforce Access Control Lists or other authorization rules when dfs.permissions.enabled is false, or does the setting bypass the permission checker entirely? What is the documented interaction between Kerberos-authenticated principals and HDFS authorization when the permission model is disabled? Does the DataNode block token mechanism provide any independent authorization protection in this configuration, or is it strictly an authentication and data integrity control?

Siddharth · Answer

Answer to the core question
When dfs.permissions.enabled is set to false, the NameNode bypasses the POSIX permission checker entirely. Any Kerberos‑authenticated principal can read, write, or delete any file or directory, regardless of ACL entries or mode bits.
What the setting actually turns off

POSIX mode bits (owner, group, others)
Access Control Lists (ACLs) – they are part of the same permission model and are ignored.
Any built‑in Hadoop authorization plug‑ins that rely on the permission checker.

Kerberos remains the sole authentication mechanism. If a client presents a valid Kerberos ticket, the NameNode will accept the request and forward it to the DataNode. The DataNode uses block tokens for authentication and data integrity, but it does not enforce path‑level access control.
Potential exceptions in newer releases
Starting with Hadoop 4.x, the authorization framework has been extended to allow optional plug‑ins that can enforce ACLs even when dfs.permissions.enabled is false. If your cluster uses such a plug‑in, you must explicitly enable it in core-site.xml (e.g., dfs.authorization.enabled). Verify the Hadoop version and any custom plug‑ins before assuming ACLs are completely disabled.
Verification steps for your cluster

Confirm the Hadoop version:
hdfs version
Check the current setting:
hdfs getconf -confKey dfs.permissions.enabled
Test with two Kerberos principals:
kinit [contact removed]
hdfs dfs -mkdir /tmp/perm_test
hdfs dfs -chmod 700 /tmp/perm_test
hdfs dfs -ls /tmp/perm_test

kinit [contact removed]
hdfs dfs -ls /tmp/perm_test

If the second command succeeds, permissions are not enforced.
Inspect NameNode logs for permission‑checker activity. When permissions are disabled, you should see no “Permission denied” or “AccessControlException” entries for successful operations.
Optionally, verify that ACLs are ignored by attempting to set an ACL and then accessing the path with a non‑owner principal.

Key takeaway
In a Kerberized cluster with dfs.permissions.enabled=false, HDFS does not enforce ACLs or POSIX permissions; authentication remains required, but authorization is effectively disabled unless you deploy a separate authorization plug‑in in a newer Hadoop release.

Does HDFS enforce authorization checks when dfs.permissions.enabled is false on a Kerberized cluster?

1 answer

Answer to the core question

What the setting actually turns off

Potential exceptions in newer releases

Verification steps for your cluster

Key takeaway

Your perspective belongs here.

0 question comments