The group mapping authz is a bit different. It's not context sensitive, as in a user uniformly belongs to groups across the whole namesystem.
Mmmhh, I’d argue that it is context sensitive, 'user' context, just a different context.
Path-based context sensitivity is adding hidden magic to a filesystem. How will the special magic be represented to the user confused by why the perms/ACLs aren't being honored?
The authorization enforcement semantics does not change at all. The plugin cannot change the permission check logic.
The plugin is responsible for providing user/group/permissions/ACLs information to the NN who enforces the permissions consistently regardless of the plugin in use.
How will permission apis and FsShell interact with the magic?
The work as usual. Check the attached patch, the current HDFS user/group/permission/ACLs handling is done by a plugin implementation.
Said that, a plugin implementation may decide to disable changes of user/group/permissions/ACLs. This can be done either silently or failing.
Instead of trying to hack special behavior for a specific use case into the NN, how about leveraging what's there.
The proposal doc describes in detail 3 different usecases: HiveMetaStore tables, Hbase tables, Solr search collections.
A cleaner way may be for a custom group mapping to fabricate groups something like "hive:table" or "hive:table:column". No code changes in the NN. Everything is contained in the custom groups mapping.
This does not solve the problem. When adding a directory as a HiveMetaStore table partition, unless you set those special groups explicitly, they would not be in the files being added to the table.
It requires client side group manipulation and this is what breaks things.
I still think leveraging ACLs is the best way to go...
Actually, we are. In the case of HiveMetaStore, the plugin would expose GRANT permissions as ACLs.
Daryn, I'm happy to jump on the phone if you want have a synchronous discussion.