accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Tubbs (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-1578) Connector constructor doesn't need to fail-fast (maybe?)
Date Thu, 18 Jul 2013 22:04:49 GMT


Christopher Tubbs commented on ACCUMULO-1578:

[~vines] - No, there *is* something different between the old system and the new pluggable
authentication. The previous assumption was that credentials were long-lived, and thus an
early check made sense, because it could be assumed that later checks would pass if an earlier
check passed. If a password changed, it's probably because the user knew about it and meant
to change it. In the pluggable authentication system, the assumption that credentials are
long-lived, or were changed as a result of deliberate user action, both go completely out
the window. Credentials can be instantiated temporarily from a credential-providing service,
and expire quite quickly. There is no reason to assume they are long-lived.

The additional check doesn't really provide much protection against changed passwords anyway...
its just a slight sanity check, for convenience, at the cost of an extra RPC call.

As the developer who coded this sanity check in the first place, I'm arguing that it's not
really worth it, but I agree that changing the contract could be disruptive. I'm trying to
get a sense of how disruptive... especially since we've never really *documented* this contract
outside the implementing code (to my knowledge).

> Connector constructor doesn't need to fail-fast (maybe?)
> --------------------------------------------------------
>                 Key: ACCUMULO-1578
>                 URL:
>             Project: Accumulo
>          Issue Type: Task
>            Reporter: Christopher Tubbs
>            Assignee: Christopher Tubbs
>             Fix For: 1.6.0
>   Original Estimate: 0.25h
>  Remaining Estimate: 0.25h
> Currently, when one instantiates a Connector from an Instance, with one's username and
token, the Connector actually tries to reach out and authenticate those credentials, to provide
early failure.
> Because this has some overhead, we explicitly check for the condition that the user is
a system user (a tserver or the monitor, etc.), so that we don't fail early in these conditions
(because we don't expect the system to be poorly configured or running in a bad state, such
that it doesn't authenticate... and we don't care about causing an inconvenience to unauthorized
servers by failing late).
> After some thought, I'm not sure that we should continue to fail fast. I'm not sure that
it provides sufficient convenience for users to warrant the additional RPC calls. Besides,
there's no guarantee, especially with the new pluggable authentication introduced in 1.5.0,
that the credentials will still be valid later, even if the user were able to authenticate
> As such, I propose we drop this check, and rely on authentication failures later (when
work is actually initiated).

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message