+1 - really useful in Hadoop for non-secure clusters.
On Wed, Jun 21, 2017 at 1:00 PM, Jean-Daniel Cryans <[email protected]> wrote: > +1, might as well allow it. > > On Wed, Jun 21, 2017 at 10:52 AM, Todd Lipcon <[email protected]> wrote: > >> Hey folks, >> >> I had the occasion yesterday of trying to run an admin tool from my laptop >> (as user 'todd') against an insecure cluster (running as user 'kudu'). The >> cluster was rejecting me because I wasn't in the admin/service ACLs, which >> was somewhat annoying. >> >> I worked around the problem by locally hacking my copy of user.cc to ignore >> my actual username and just return "kudu" :) >> >> I think it's good that we have authorization enabled even in insecure >> clusters, since it reduces test variables and prevents "accidental" usage >> of higher privileges. So, I don't think we should disable the above >> behavior. >> >> That said, it's inconvenient to have to recompile Kudu to spoof a user >> against an insecure cluster. Given that it's already easy to spoof for a >> malicious user, does anyone have an objection to making it easier for >> non-malicious users to spoof by respecting some environment variable like >> KUDU_USER or KUDU_INSECURE_USER or KUDU_SPOOF_USER or somesuch? >> >> -Todd >> -- >> Todd Lipcon >> Software Engineer, Cloudera >>
