> > > On 9/26/17 11:27 AM, Andrew Purtell wrote: > > It would be a major functional change. Someone might be relying on the > > table ownership semantic. However, 2.0 would be the next opportunity to > > introduce a change of this type before 3.0. > > > > I don't think we need table owners. It is a shortcut in the permissions > > model which is good for usability but bad for adding complexity. Removing > > the shortcut would make it more likely we'd see odd situations like > where a > > user can create a table but surprisingly lack other permissions, but that > > would be a consequence of mismanagement of grants by cluster admins, not > a > > bug or functional gap introduced by removing table ownership. > > +1 well put. > > +1 as well.
Table owners were originally an approximation of delegated admin functionality -- basically you can admin what you create. The metadata aspect of table owners (HBASE-11996) still seems useful. But, like Andy says, the access control aspect just adds some implicit complexity without much benefit. For a delegated admin scenario, making this explicit with ADMIN permission over a specific table or namespace would be a more manageable and more transparent approach. Removing the built-in grants generated with table owners seems like a good step forward.
