accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Tubbs" <ctubbsii...@apache.org>
Subject Re: Review Request 29386: ACCUMULO-2815 Client authentication via Kerberos
Date Mon, 05 Jan 2015 20:36:23 GMT


> On Dec. 30, 2014, 5:46 p.m., Christopher Tubbs wrote:
> > core/src/main/java/org/apache/accumulo/core/client/security/tokens/KerberosToken.java,
lines 71-79
> > <https://reviews.apache.org/r/29386/diff/4/?file=803145#file803145line71>
> >
> >     Why is this unsupported?
> 
> Josh Elser wrote:
>     Again, see earlier discussion. I have no idea what this is actually supposed to destroy
(we have zero documentation on the matter that I found) and it's already been changed to be
a noop. I am just as confident that a noop is correct as an unsupported operation is correct
(I have no confidence).
>     
>     As far as destroying a UGI, I haven't found any parallel to the Destroyable interface.
I'm not sure if something exists that we should be calling.

It's a way for objects to remove their internal state (preferably by securely overwriting
memory) so any credentials can be removed from memory, to give the user control over their
credentials. It is expected to be called by the user.

In the earlier implementation, setting the ugi to null would have been appropriate. In the
latest version, you can nullify the principal. It's not terribly important, since the principal
alone is not sensitive, but it would be helpful to have reasonable behavior when the user
calls these methods to avoid things like "I called destroy, but it won't destroy!" or "My
application verifies the token isn't destroyed before using it, but it seems to always be
destroyed!".

Even if it was a truly no-op, we could add an internal "destroyed" flag to give users reasonable
behavior. Since we do have the principal, we can just make that null instead of adding a new
flag, and use that to check the state of its destruction.

Also, I think the other methods which assume it is not destroyed should throw IllegalStateException
explicitly if it is, in fact, destroyed. But, I'm not even sure we do that in the other tokens,
so it's probably fine to leave that behavior undefined.


> On Dec. 30, 2014, 5:46 p.m., Christopher Tubbs wrote:
> > core/src/main/java/org/apache/accumulo/core/client/security/tokens/KerberosToken.java,
lines 52-69
> > <https://reviews.apache.org/r/29386/diff/4/?file=803145#file803145line52>
> >
> >     The no-arg constructor is used for Writable, and is used to serialize credentials
to a file. This is useful for MapReduce.
> >     
> >     As is, this *should* work, as long as the user wishes to use the UserGroupInformation.getLoginUser().
However, that basically forces the MapReduce task to use the MapReduce task's own credentials,
to talk to Accumulo, and not the user's. This could be a cumbersome pitfall.
> >     
> >     Is there a way to serialize the user's ugi, so that it can be de-serialized,
falling back on the UserGroupInformation.getLoginUser() if the user's ugi cannot be deserialized?
> >     
> >     At the very least, the serialization should store *something* (magic bytes which
refer to "nothing here"), so we can distinguish between that and future serialized options,
if we add any later.
> 
> Josh Elser wrote:
>     MapReduce is something I need to investigate and test. I have no idea how token delegation
works with MapReduce (if it's anything more than "use a keytab"). If it's that, this approach
should be fine. Otherwise, it'll be problematic.
>     
>     I've also switched this from loginUser to currentUser (I think in the most recent
patch) as I think loginUser was incorrect.
>     
>     I'll add some magic bytes to the serialization.

Saw the latest version with the magic bytes. Might be easier to use `private int ver = 1;`
and `out.writeInt(ver);`.


> On Dec. 30, 2014, 5:46 p.m., Christopher Tubbs wrote:
> > core/src/main/java/org/apache/accumulo/core/conf/Property.java, lines 165-167
> > <https://reviews.apache.org/r/29386/diff/4/?file=803146#file803146line165>
> >
> >     I don't think we want to expose this. It's high risk. What is the reason and
how is it related to this change?
> 
> Josh Elser wrote:
>     Again, see the previous discussion on this subject. This is necessary to actually
perform an apples to apples comparison of the impact of Kerberos on Accumulo. Comparing KRB/SASL
with TThreadPoolServer against no KRB/SASL and THsHaServer is an invalid benchmark to determine
the overhead of KRB.
>     
>     Like I said earlier, `Experimental` is not really the appropriate annotation here
(Internal use would be more accurate), but it's what we have. Do you have a recommendation
on some other change in wording/annotation to convey the intent?
>     
>     I'd like to not have to change the codebase any time I want to verify no performance
regressions in future versions (having to change code would preclude any non-devs from running
their own benchmarks too).

My main concern is that I'm not entirely confident we're not exposing these to users in some
way, still: see ACCUMULO-2460 and ACCUMULO-2401.


> On Dec. 30, 2014, 5:46 p.m., Christopher Tubbs wrote:
> > core/src/main/java/org/apache/accumulo/core/rpc/UGIAssumingTransport.java, lines
61-64
> > <https://reviews.apache.org/r/29386/diff/4/?file=803151#file803151line61>
> >
> >     This is what AssertionError is for.
> 
> Josh Elser wrote:
>     No, they should throw RuntimeException. The comment is meant that those exceptions
weren't thrown from the doAs block. They should just wrap the exceptions in a RuntimeException
and let thrift do the correct thing.

Ah, I misunderstood the message as "impossible to occur" when it now appears to be a "wasn't
me" situation.


> On Dec. 30, 2014, 5:46 p.m., Christopher Tubbs wrote:
> > server/base/src/main/java/org/apache/accumulo/server/init/Initialize.java, lines
285-293
> > <https://reviews.apache.org/r/29386/diff/4/?file=803157#file803157line285>
> >
> >     It was discussed in the context of ACCUMULO-259 that the root user would be
a built-in, password-based user, even if other auth mechanisms were available (like Linux
root user). Some proposals were made to make this easier to work with and more intuitive for
users, but the initialization of the root user should really just be the 
> >     
> >     See ACCUMULO-1300 and related issues, for more details.
> >     
> >     What are the risks of making the root user rely on Kerberos?
> 
> Josh Elser wrote:
>     Thanks for the background; I didn't remember this discussion.
>     
>     Hadoop does have a similar approach that we could adopt but I'm extremely hesitant
to recommend we do it (because I think it's some of the ugliest configuration in Hadoop).
Look up hadoop.security.auth_to_local: (first result from google for me http://hortonworks.com/blog/fine-tune-your-apache-hadoop-security-settings/).
Essentially, we could introduce this very convoluted user mapping into the "root" user. Personally,
I think this is much more confusing.
>     
>     I regret not being a part of the previous discussion, but I don't understand why
we should rely on always having a password based user. It seems like forcing us into edge-case-city.
Do you have more information on this discussion? I didn't find anything on ACCUMULO-259 on
it and I want to make sure I'm up to speed. Comparing our "root" user is the Linux root user
is a bit of a fallacy in my opinion because they're not equivalent. In a properly configured
system, root should never be used by anyone but an administrator to delegate permissions or
perform one-time tasks (to avoid permission delegation).
>     
>     In my opinion, avoid some "magical" user helps with the auditing and authentication
Accumulo uses as a whole. Each client that comes into Accumulo is a user. They have a Kerberos
identity and we treat them as the "Accumulo user" based on that Kerberos identity. The internal
"!SYSTEM" user is the only other user; however it is still identified by a specific Kerberos
identity (the ones we know the servers use to log in).
>     
>     Also, this may benefit from non-reviewboard discussion, please feel free to pop this
over to the ML.

As far as I know, all the conversation happened in the comments on ACCUMULO-259 and it's linked
issues, as well as on the mailing list, but I don't have direct references, other than the
issues I linked.

The root user as compared to the Linux root user is analogous, not equivalent. I agree that
a root user should never be used except to delegate and perform one time tasks. The problem
is that, like the Linux root user, it is sometimes needed to do these tasks when other components
of the system (such as the pluggable authentication service) are unavailable. The same permissions
could be delegated to an admin in that service, so the built-in root would be even less frequently
used, but it still might be needed. This is the same reasoning as setting a BIOS password,
or Linux root user, or MySQL root user, or Hadoop SuperUser, or ZK's "super" user.

The point may be moot, though, if the system is completely unusable if Kerberos is down (because
the system token relies on Kerberos). Though... I can see a use case for restarting the system
with Kerberos disabled to do maintenance and to have root available for that.

As for the system user being a Kerberos identity, see my other concerns regarding that.


> On Dec. 30, 2014, 5:46 p.m., Christopher Tubbs wrote:
> > server/base/src/main/java/org/apache/accumulo/server/security/SystemCredentials.java,
lines 62-63
> > <https://reviews.apache.org/r/29386/diff/4/?file=803163#file803163line62>
> >
> >     What is the reason for making SystemCredentials able to use Kerberos? SystemCredentials
are how the system identifies itself to itself. It's all internal. It shouldn't rely on external
components, in my opinion.
> 
> Josh Elser wrote:
>     The point is that the same identity that we use to authenticate clients should be
used to authenticate servers. In the same vein that the SystemCredentials precludes rogue
server processes from participating in the instance, relying on a specific principal to identify
"valid" servers for this instance guarantees the same thing.
> 
> Josh Elser wrote:
>     Going back through this, your comment bothers me still and I don't think I did it
justice as succinctly as I could the first time. Kerberos provides *strong authentication*
-- clients or servers use it. Just as we want to be assured that clients are who they say
they are, we want the same guarantee for servers. We also *need* strong authentication for
both to even talk to HDFS, so it makes no sense to me to try to say that our servers shouldn't
be using kerberos.

In short, I'm okay with this, assuming we can distinguish between the server component and
a user using Kerberos on that same system (maybe a configuration item to define the system
Kerberos principal [instance.kerberos.principal]? essentially, a less sensitive instance.secret.),
and we retain all the sanity checks / hashing of the required common configuration / instance
ID.

I'm not arguing against the strong authentication or against using Kerberos for the servers.
Just that all the goodness that the system credentials have right now needs to be checked
also. We can do that by using the strongly authenticated transport, and just using the current
SystemToken to verify the rest. The SystemToken, after all, is providing validation that it
is a system component, with all the correct configuration to properly act as one, and not
that it is who it says it is.

I'd also like to have a plan moving forward with ACCUMULO-1300 (I don't think that plan would
be very complicated... just a special authenticator for system credentials which works with
and without Kerberos enabled, and does the proper validation checks that we have now).


> On Dec. 30, 2014, 5:46 p.m., Christopher Tubbs wrote:
> > server/base/src/main/java/org/apache/accumulo/server/security/SystemCredentials.java,
line 106
> > <https://reviews.apache.org/r/29386/diff/4/?file=803163#file803163line106>
> >
> >     The SystemToken should be a separate type. it is not a password token. It is
a token type that is exclusive to the system (it's even final, so it cannot be sub-class'd).
It should not be swapped out with Kerberos tokens, or any other kind of token.
> >     
> >     It should also not be considered a password token. That just happens to be the
closest analogy to the current implementation. It's really it's own special type.
> >     
> >     However, there is a proposal to make individual components authenticate, but
I don't think this achieves that: ACCUMULO-1165
> 
> Josh Elser wrote:
>     bq. it is not a password token
>     
>     Really? It generates a secret and uses it to authenticate with a server. That sounds
like a password to me :).
>     
>     Seriously though, I respect that you have concerns here, but I don't have the foggiest
idea of what you think this should be changed to do.
>     
>     Kerberos gives each server a unique token (authenticated against the KDC) via their
keytab. We ensure rogue servers cannot participate in the instance by requiring the primary
in the principal ('accumulo' in '`accumulo/_HOST@EXAMPLE.COM`'). SASL is also ensuring that
an RPC cannot even establish a connection to Accumulo servers. What piece of the puzzle are
we missing and how do you think this should operate?

I don't think it needs to be renamed. It's a misleading rename. It's only a "password" in
the same sense that all authentication tokens are essentially passwords, but not in the narrow
scope that we think of passwords that people remember and use to log in. It's not even human-readable,
except for the fact that we encode the hash with a printable character set.

I think it'd be better to make the existing SystemToken be made Kerberos-aware, rather than
create two separate token types which are swapped out. I think that achieves the existing
goals, as well as the new Kerberos features. This also makes it easier to move forward with
ACCUMULO-1300, solidifying the idea that the system token is checked by the system authenticator.


> On Dec. 30, 2014, 5:46 p.m., Christopher Tubbs wrote:
> > server/base/src/main/java/org/apache/accumulo/server/security/SystemCredentials.java,
lines 153-168
> > <https://reviews.apache.org/r/29386/diff/4/?file=803163#file803163line153>
> >
> >     This should not be here. Using Kerberos for the SystemToken removes an important
check against rogue servers from other instances communicating with the current instance.
> >     
> >     It also removes all the other mandatory checks in the SystemToken which protect
against incompatible variations in the "instance.*" properties, which are encapsulated in
the SystemToken's hash.
> 
> Josh Elser wrote:
>     bq. from other instances communicating with the current instance
>     
>     Not true. It, along with the KerberosAuthenticator/SecurityOperation, guarantees
that only servers with a primary component of their principal matching the `general.kerberos.principal`
value in accumulo-site.xml can communicate with the instance. One would assume that separate
realms or primaries are used for Accumulo instances sharing the same KDC, but we could try
to make this stronger by (somehow) incorporating the rest of the `instance.` properties. I
don't know how to approach this, however, and am open to suggestions.

Making the existing SystemToken Kerberos-aware, and doing the validation of the existing hash
after authenticating with Kerberos would work.


> On Dec. 30, 2014, 5:46 p.m., Christopher Tubbs wrote:
> > server/base/src/main/java/org/apache/accumulo/server/security/handler/KerberosAuthenticator.java,
line 41
> > <https://reviews.apache.org/r/29386/diff/4/?file=803164#file803164line41>
> >
> >     I don't think this should be so tightly coupled with the ZKAuthenticator. It
doesn't seem that this coupling is necessary to provide authentication functionality.
> >     
> >     Have a different implementation of an Authenticator that hijacks the data storage
of another implementation, could be quite confusing to administrators, especially if they
need to swap out the implementation.
> >     
> >     See ACCUMULO-1300 and related issues for other options.
> 
> Josh Elser wrote:
>     I understand the intentions for ACCUMULO-1300; however, that's not implemented. Being
able to leverage the existing ZKAuthorizor was wonderful so I really don't want to move away
from how this fundamentally works.
>     
>     Shouldn't the Authenticator and Authorizor be fixed per instance (allowing reset
via `accumulo init --reset-security` or w/e)? What do you actually want changed aside from
documentation to make it clear to administrators (I haven't written any documentation yet).

So, I pointed out in the conversation around ACCUMULO-259, that I would prefer a pluggable
security module that integrated all the security-related functions, because they are so dependent
on each other. However, they were implemented as 3 separately configurable pluggable components.
I would still like to see them merged (which doesn't preclude making one from modular components
themselves).

For now, I'm not really sure what it means for somebody to "create a user" when the authenticator
already validates them. That's why it's confusing. Are we essentially making ZKAuthenticator
Kerberos-aware, or are we providing a separate Kerberos Authenticator? That's really what
it boils down to for me. It seems like we're doing a hybrid... but I think we should solidify
on one or the other.


> On Dec. 30, 2014, 5:46 p.m., Christopher Tubbs wrote:
> > server/base/src/main/java/org/apache/accumulo/server/security/handler/KerberosAuthenticator.java,
line 46
> > <https://reviews.apache.org/r/29386/diff/4/?file=803164#file803164line46>
> >
> >     Why is this seed fixed?
> 
> Josh Elser wrote:
>     To keep using ZKAuthenticator as a "delegate", I need to put some password into ZK.
I don't think it's required that these random strings actually be secure, it's mostly intended
as obfuscation. Thoughts?

If it's not intended to be secure, why use SecureRandom in the first place? And, because ZK
is being used as a delegate, and because these are being used in place of a password, I think
they should be secure. If somebody changed from the KerberosAuthenticator back to the default
(which is easy to do, if one accidentally clobbers the configuration file when upgrading a
system), non-secure passwords could actually be used to authenticate. If you really want to
store something which cannot be used to authenticate, you need to replace it with something
that cannot parse as a hashed password. This is what happens in /etc/shadow when you disable
an account.

In any case, I still don't see the need to do anything with the seed. SecureRandom does special
stuff with the seed, and I'm not sure it is needed to set it. setSeed doesn't even behave
the same way as regular Random does with a fixed seed. It doesn't seem "wrong". It just seems
like unnecessary code.


> On Dec. 30, 2014, 5:46 p.m., Christopher Tubbs wrote:
> > shell/src/main/java/org/apache/accumulo/shell/ShellOptionsJC.java, lines 176-180
> > <https://reviews.apache.org/r/29386/diff/4/?file=803175#file803175line176>
> >
> >     Descriptions are not consistent with capitalization. ("Use" vs. "use")
> 
> Josh Elser wrote:
>     Obligatory, it bothers me that they're all lowercase :)

Make them all upper-case :)


> On Dec. 30, 2014, 5:46 p.m., Christopher Tubbs wrote:
> > shell/src/main/java/org/apache/accumulo/shell/ShellOptionsJC.java, line 210
> > <https://reviews.apache.org/r/29386/diff/4/?file=803175#file803175line210>
> >
> >     Why is username the "short" user name? Is that unique in Kerberos? If not, the
long version should be used everywhere instead. Otherwise, one user can appear to be another
in logs, etc.
> >     
> >     If "getShortUserName" is not unique, it should avoided everywhere.
> 
> Josh Elser wrote:
>     Check out: http://web.mit.edu/kerberos/krb5-1.5/krb5-1.5.4/doc/krb5-user/What-is-a-Kerberos-Principal_003f.html
>     
>     Kerberos principals are of the form: primary/instance@realm. Kerberos principals
are typically categorized as users and services. A user is not qualified to a single instance
(a host) and represent authentication across the realm. For example, elserj@EXAMPLE.COM means
that I can "roam". Conversely, a service is typically "fixed" to a specific host. For example,
accumulo/node1.example.com@EXAMPLE.COM means that there is a process, logged in as 'accumulo'
on the host 'node1.example.com'. That service can't be run on any other host. Now, an important
note if someone actually creates a principal "accumulo@EXAMPLE.COM" this is unique with respect
to any other "accumulo/`host`@EXAMPLE.COM" principal. I'm not sure if we need to do anything
else other than convention of kerberos principals, or if we should be including the instance
in "our" username when present.
>     
>     This kind of ties back into the SystemCredentials discussion again.

Okay, so a smart configuration would make shortnames unique. However, UserGroupInformation
returns only the `primary` for the short name. This means that user names will have to be
unique across realms and instances. Right now, you are storing permissions using the short
name. So, any user with the same primary, will be able to masquerade as any other user with
the same primary from a different instance and/or realm, and be able to user their permissions
and authorizations. That's the problem with the shortname here. That's very unexpected.


- Christopher


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/29386/#review66382
-----------------------------------------------------------


On Dec. 31, 2014, 4:24 p.m., Josh Elser wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/29386/
> -----------------------------------------------------------
> 
> (Updated Dec. 31, 2014, 4:24 p.m.)
> 
> 
> Review request for accumulo.
> 
> 
> Bugs: ACCUMULO-2815
>     https://issues.apache.org/jira/browse/ACCUMULO-2815
> 
> 
> Repository: accumulo
> 
> 
> Description
> -------
> 
> ACCUMULO-2815 Initial support for Kerberos client authentication.
> 
> Leverage SASL transport provided by Thrift which can speak GSSAPI, which Kerberos implements.
Introduced...
> 
> * An Accumulo KerberosToken which is an AuthenticationToken to validate users.
> * Custom thrift processor and invocation handler to ensure server RPCs have a valid KRB
identity and Accumulo authentication.
> * A KerberosAuthenticator which extends ZKAuthenticator to support Kerberos identities
seamlessly.
> * New ClientConf variables to use SASL transport and pass Kerberos server principal
> * Updated ClientOpts and Shell opts to transparently use a KerberosToken when SASL is
enabled (no extra client work).
> 
> I believe this is the "bare minimum" for Kerberos support. They are also grossly lacking
in unit and integration tests. I believe that I might have somehow broken the client address
string in the server (I saw log messages with client: null, but I'm not sure if it's due to
these changes or not). A necessary limitation in the Thrift server used is that, like the
SSL transport, the SASL transport cannot presently be used with the TFramedTransport, which
means none of the [half]async thrift servers will function with this -- we're stuck with the
TThreadPoolServer.
> 
> Performed some contrived benchmarks on my laptop (while still using it myself) to get
at big-picture view of the performance impact against "normal" operation and Kerberos alone.
Each "run" was the duration to ingest 100M records using continuous-ingest, timed with `time`,
using 'real'.
> 
> THsHaServer (our default), 6 runs:
> 
> Avg: 10m7.273s (607.273s)
> Min: 9m43.395s
> Max: 10m52.715s
> 
> TThreadPoolServer (no SASL), 5 runs:
> 
> Avg: 11m16.254s (676.254s)
> Min: 10m30.987s
> Max: 12m24.192s
> 
> TThreadPoolServer+SASL/GSSAPI (these changes), 6 runs:
> 
> Avg: 13m17.187s (797.187s)
> Min: 10m52.997s
> Max: 16m0.975s
> 
> The general takeway is that there's about 15% performance degredation in its initial
state which is in the realm of what I expected (~10%).
> 
> 
> Diffs
> -----
> 
>   core/src/main/java/org/apache/accumulo/core/cli/ClientOpts.java f6ea934 
>   core/src/main/java/org/apache/accumulo/core/client/ClientConfiguration.java 6fe61a5

>   core/src/main/java/org/apache/accumulo/core/client/impl/ClientContext.java e75bec6

>   core/src/main/java/org/apache/accumulo/core/client/impl/ConnectorImpl.java f481cc3

>   core/src/main/java/org/apache/accumulo/core/client/impl/ThriftTransportKey.java 6dc846f

>   core/src/main/java/org/apache/accumulo/core/client/impl/ThriftTransportPool.java 5da803b

>   core/src/main/java/org/apache/accumulo/core/client/security/tokens/KerberosToken.java
PRE-CREATION 
>   core/src/main/java/org/apache/accumulo/core/conf/Property.java e054a5f 
>   core/src/main/java/org/apache/accumulo/core/rpc/FilterTransport.java PRE-CREATION 
>   core/src/main/java/org/apache/accumulo/core/rpc/SaslConnectionParams.java PRE-CREATION

>   core/src/main/java/org/apache/accumulo/core/rpc/TTimeoutTransport.java 6eace77 
>   core/src/main/java/org/apache/accumulo/core/rpc/ThriftUtil.java 09bd6c4 
>   core/src/main/java/org/apache/accumulo/core/rpc/UGIAssumingTransport.java PRE-CREATION

>   core/src/main/java/org/apache/accumulo/core/rpc/UGIAssumingTransportFactory.java PRE-CREATION

>   core/src/main/java/org/apache/accumulo/core/security/Credentials.java 525a958 
>   core/src/test/java/org/apache/accumulo/core/cli/TestClientOpts.java ff49bc0 
>   core/src/test/java/org/apache/accumulo/core/client/ClientConfigurationTest.java PRE-CREATION

>   core/src/test/java/org/apache/accumulo/core/conf/ClientConfigurationTest.java 40be70f

>   core/src/test/java/org/apache/accumulo/core/rpc/SaslConnectionParamsTest.java PRE-CREATION

>   proxy/src/main/java/org/apache/accumulo/proxy/Proxy.java 4b048eb 
>   server/base/src/main/java/org/apache/accumulo/server/AccumuloServerContext.java 09ae4f4

>   server/base/src/main/java/org/apache/accumulo/server/init/Initialize.java 046cfb5 
>   server/base/src/main/java/org/apache/accumulo/server/rpc/TCredentialsUpdatingInvocationHandler.java
PRE-CREATION 
>   server/base/src/main/java/org/apache/accumulo/server/rpc/TCredentialsUpdatingWrapper.java
PRE-CREATION 
>   server/base/src/main/java/org/apache/accumulo/server/rpc/TServerUtils.java 641c0bf

>   server/base/src/main/java/org/apache/accumulo/server/rpc/ThriftServerType.java PRE-CREATION

>   server/base/src/main/java/org/apache/accumulo/server/security/SecurityOperation.java
5e81018 
>   server/base/src/main/java/org/apache/accumulo/server/security/SecurityUtil.java 29e4939

>   server/base/src/main/java/org/apache/accumulo/server/security/SystemCredentials.java
a59d57c 
>   server/base/src/main/java/org/apache/accumulo/server/security/handler/KerberosAuthenticator.java
PRE-CREATION 
>   server/base/src/main/java/org/apache/accumulo/server/thrift/UGIAssumingProcessor.java
PRE-CREATION 
>   server/base/src/test/java/org/apache/accumulo/server/AccumuloServerContextTest.java
PRE-CREATION 
>   server/base/src/test/java/org/apache/accumulo/server/rpc/TCredentialsUpdatingInvocationHandlerTest.java
PRE-CREATION 
>   server/base/src/test/java/org/apache/accumulo/server/security/SystemCredentialsTest.java
4202a7e 
>   server/gc/src/main/java/org/apache/accumulo/gc/SimpleGarbageCollector.java 93a9a49

>   server/gc/src/test/java/org/apache/accumulo/gc/GarbageCollectWriteAheadLogsTest.java
f98721f 
>   server/gc/src/test/java/org/apache/accumulo/gc/SimpleGarbageCollectorTest.java 99558b8

>   server/gc/src/test/java/org/apache/accumulo/gc/replication/CloseWriteAheadLogReferencesTest.java
cad1e01 
>   server/master/src/main/java/org/apache/accumulo/master/Master.java 12195fa 
>   server/tracer/src/main/java/org/apache/accumulo/tracer/TraceServer.java 7e33300 
>   server/tserver/src/main/java/org/apache/accumulo/tserver/TabletServer.java d5c1d2f

>   shell/src/main/java/org/apache/accumulo/shell/Shell.java 58308ff 
>   shell/src/main/java/org/apache/accumulo/shell/ShellOptionsJC.java 8167ef8 
>   shell/src/test/java/org/apache/accumulo/shell/ShellConfigTest.java 0e72c8c 
>   shell/src/test/java/org/apache/accumulo/shell/ShellOptionsJCTest.java PRE-CREATION

>   test/src/main/java/org/apache/accumulo/test/functional/ZombieTServer.java eb84533 
>   test/src/main/java/org/apache/accumulo/test/performance/thrift/NullTserver.java 2ebc2e3

>   test/src/test/java/org/apache/accumulo/server/security/SystemCredentialsIT.java fb71f5f

> 
> Diff: https://reviews.apache.org/r/29386/diff/
> 
> 
> Testing
> -------
> 
> Ensure existing unit tests still function. Accumulo is functional and ran continuous
ingest multiple times using a client with only a Kerberos identity (no user/password provided).
Used MIT Kerberos with Apache Hadoop 2.6.0 and Apache ZooKeeper 3.4.5.
> 
> 
> Thanks,
> 
> Josh Elser
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message