> On Dec. 30, 2014, 10: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, els...@example.com means that I can "roam". > Conversely, a service is typically "fixed" to a specific host. For example, > accumulo/node1.example....@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 "accum...@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. > > Christopher Tubbs wrote: > 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.
Bingo. If you look at how HDFS does their configuration, this is the same convention. The lack of documentation from me leaves something to be desired here, and I apologize for that. To save you looking at HDFS (if you care not to look), you'll see that an HDFS process uses a given principal with a special replacement string `_HOST`. The common convention is to use something like `dn/_h...@example.com` (the realm is unimportant for this example). This ensures that the same configuration files can be used across all hosts in the HDFS instance, and Hadoop dynamically replaces `_HOST` with the FQDN of the host. Thus, there's an implicit link that all `dn/*@EXAMPLE.COM` can act as datanodes and this is protected by the fact that access to the KDC is restricted (you can't make your own user). The circle of trust is two-fold: having a keytab with the correct principal and that Hadoop is requires that specific configuration (which restricts the principal). > On Dec. 30, 2014, 10: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? > > Christopher Tubbs wrote: > 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. Ok, I can just remove the seed, then. > On Dec. 30, 2014, 10: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. > > Christopher Tubbs wrote: > Saw the latest version with the magic bytes. Might be easier to use > `private int ver = 1;` and `out.writeInt(ver);`. Oh, ok. That's even simpler. Will adopt. > On Dec. 30, 2014, 10: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. > > Christopher Tubbs wrote: > 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. WRT UserGroupInformation, I don't know how (or if I even can) destroy the current login which is.. awkward to me. Generally speaking, this would be great to get written down somewhere -- I'll try to fire up a ticket for that so we don't have this discussion again in 6mos. > On Dec. 30, 2014, 10: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). > > Christopher Tubbs wrote: > 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. It sounds to me like we should introduce a new annotation then to cover things not meant for user consumption. Experimental is for "maybe not stable or entirely working" user facing things. This property is (likely) only relevant for developers. Any objections to addressing this by introduction of a new annotation (not in this changeset)? > On Dec. 30, 2014, 10: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. > > Christopher Tubbs wrote: > 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. bq. 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. I kind of see what's done here as analogous to what Hadoop already provides -- a single, well-defined user with `System.SYSTEM`. bq. The point may be moot, though, if the system is completely unusable if Kerberos is down (because the system token relies on Kerberos). Yes, that's accurate. bq. Though... I can see a use case for restarting the system with Kerberos disabled to do maintenance and to have root available for that. I think this would be wrong. If the KDC is down, you're already going to be unable to connect to HDFS or ZooKeeper. Allowing a "backdoor" into the instance without the (strong) Kerberos identity seems like a security risk to me. I still have to think about the "re-initialization" problem (both malicious and benign as "I lost my credentials"). I'm also a bit worried about trying to tackle the "change authentication handlers" problem in the first patch as this is already gettin really big (despite my best efforts). > On Dec. 30, 2014, 10: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. > > Christopher Tubbs wrote: > 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). bq. 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.) I was wondering about this initially as the kerberos properties are under `general.`. If we move them to `instance.`, we can make sure that we have consistency (via the below) like you suggested). I think this would also help with the other discussion we had about a username compared to a service name on a host. bq. we retain all the sanity checks / hashing of the required common configuration / instance ID Ok, I think I can do that. > On Dec. 30, 2014, 10: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/_h...@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? > > Christopher Tubbs wrote: > 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. bq. 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. My initial concern was to have differentiator to SystemTokens: a SystemToken and a SystemKerberosToken (or w/e) came across as odd to me. bq. 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 Since I'm going to look into the `instance.*` hashing and what-not, I'll keep this in mind. That might be enough to make it worth combining the two tokens into one and invalidate the above concerns. > On Dec. 30, 2014, 10: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). > > Christopher Tubbs wrote: > 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. I view it as a Kerberos Authenticator. The implementation details of that authenticator is that is happens to persist information into ZK to handle things like permissions and authorizations, but a user doesn't have to know that to use it. We could, hypothetically, swap out ZK for any other persistent store for that information and it would continue to work. What would help alleviate your confusion? More javadocs? A different class name? - Josh ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/29386/#review66382 ----------------------------------------------------------- On Dec. 31, 2014, 9: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, 9: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 > >
