I'm in favor of providing an easy to use workaround for this case, but I'd like to see it implemented a bit differently. I think the user name should be an option in the Kudu client builder (alongside e.g. import_authentication_credentials <https://github.com/cloudera/kudu/blob/master/src/kudu/client/client.h#L240>), and the application (in this case the kudu tool) would be responsible for reading an environment variable and setting it appropriately (or perhaps via a gflag). Same effect in the end, but I don't think pure libraries should be reading things from the environment.
All that being said, I'd also be in favor of KUDU_USER over the longer variants, since changing the username is not inherently insecure; the 'source' of the insecurity is the cluster's configuration, not the client configuration. - Dan 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 >
