I also think it's better to not introduce environment-controlled
behavior into the Kudu C++ client library itself. I'm in favor of Dan's
proposal.
If I remember correctly, there was an idea to implement some sort of
configuration for the client library via config file. That's a separate
theme on its own, but if it's going to be implemented, keeping off the
environment-controlled behavior from the client library makes more sense
in that context as well. It also makes more sense to avoid introducing
environment-controlled behavior if we want to keep the C++ and the Java
client parity to some extent.
Having the explicit run-time flag for the CLI tool might be even a
better option. And it would be nice if that worked for the Kerberized
setup as well (maybe, in the future).
Best regards,
Alexey
On 6/21/17 11:06 AM, Dan Burkert wrote:
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
