[ https://issues.apache.org/jira/browse/ACCUMULO-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13832104#comment-13832104 ]
Dave Marion commented on ACCUMULO-1928: --------------------------------------- Oh, and I'm thinking that security is something that should likely be locked down. Is there a specific use-case where security related code needs to be reloaded? > Class loader issues with building auth/auth/perm extensions > ----------------------------------------------------------- > > Key: ACCUMULO-1928 > URL: https://issues.apache.org/jira/browse/ACCUMULO-1928 > Project: Accumulo > Issue Type: Bug > Affects Versions: 1.5.0, 1.6.0 > Reporter: Michael Allen > > In the course of building extensions to take advantage of the > {{Authenticator}}, {{Authorizor}} and {{PermissionHandler}} interfaces, I ran > into several issues with how the extension classes were loaded (and reloaded) > using {{AccumuloVFSClassloader}}. These issues ultimately meant that we had > to make the decision to put these extensions into {{$ACCUMULO_HOME/lib}}, > rather than {{$ACCUMULO_HOME/lib/ext}}, so that they would not be reloaded > and we would not encounter those issues. > We should figure out how to fix up the classloader such that it makes it > possible to put extensions like these into {{$$ACCUMULO_HOME/lib/ext}}, or we > should document that it is not recommended to do so. > So what were the problems? > 1. In 1.5.0, Authentication tokens from within the extension could not be > loaded via the normal creation pathway. This pathway in {{CredentialHelper}} > includes the following line of code: > {code} > Object obj = Class.forName(tokenClass).newInstance(); > {code} > In 1.6 this code has been replaced with a call in > {{AuthenticationToken.AuthenticationTokenSerializer.deserialize()}} that uses > {{AccumuloVFSClassloader}}, but I wonder if we shouldn't also make a 1.5.X > change to at least make it possible to do it there? Otherwise anyone trying > to create an extension for 1.5.X can only use {{PasswordToken}}s > 2. Even when you do or don't fix #1, it leads you on to a different, less > tractable problem. > The {{Authenticatior}} etc. classes are loaded by {{SecurityOperation}} > singleton, using {{AccumuloVFSClassloader}} and the objects are held within > the singleton, which is held statically by the {{SecurityOperation}} class. > That's all well and good, and let's call that {{AccumuloVSFClassloader}} > instances that loaded those classes {{CL1}}. > But now let's say you stick a new version of your JAR file into > {{$ACCUMULO_HOME/lib/ext}}. {{AccumuloVFSClassloader}} happily creates a new > classloader (call it {{CL2}}) for you and reloads your classes. *However*, > the objects instantiated by {{SecurityOperation}} still owe their lineage to > {{CL1}}. When a new authentication token comes in and gets loaded by > {{CL2}}, its class name might look like a class from {{CL1}}, but when the > {{Authenticator}} that came from {{CL1}} tries to cast that {{CL2}}-based > object, you get {{ClassCastException}}s and are basically toast at that point. > One possible fix here would be for {{AccumuloVFSClassloader}} to somehow > notify interested parties that classes had reloaded so that they could flush > away any old classes if desired. There'd be some synchronization issues > around doing this, to make sure that the security stuff still worked reliably > through this process. You'd have no guarantee, though, that the rest of the > code wouldn't be hanging on to {{CL1}}-based object references and not > letting go. Beating those bugs out may require too much coder discipline to > be worth the feature. > Another possible fix is to just say "don't do that for security-related > features and put them in {{$ACCUMULO_HOME/lib}}. That's kind of giving up on > being able to reload these at runtime, but maybe that's OK. Generally > speaking, reloading your security assumptions might be something you want to > take the tablet server down for. -- This message was sent by Atlassian JIRA (v6.1#6144)