+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 >
