[jira] [Commented] (ACCUMULO-1583) RPC from "system" user with wrong credentials will kill a tablet server

["Jeffrey Manno (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/ACCUMULO-1583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17267977#comment-17267977 ] 

Jeffrey Manno commented on ACCUMULO-1583:
-----------------------------------------

This issue can be closed. After doing thorough testing and comparing accumulo versions 1.5 and 2.1, the tablet server is no longer killed by a "system" user with wrong credentials. Tested using the flush rpc command by adjusting the passed-in credentials so it would fail and the same errors show up on both versions but on 2.1, the Tablet Server isn't killed. The original issue stemmed from the code snippet below. That block of code seems to have been removed in 1.6 from what I could tell.  


{code:java}
finally {
   if (fatal) {
     Halt.halt(1, new Runnable() {
                      @Override
                      public void run() {
                        logGCInfo(getSystemConfiguration());
                      }
                    });
{code}

> RPC from "system" user with wrong credentials will kill a tablet server
> -----------------------------------------------------------------------
>
>                 Key: ACCUMULO-1583
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-1583
>             Project: Accumulo
>          Issue Type: Bug
>    Affects Versions: 1.5.0
>            Reporter: Christopher Tubbs
>            Priority: Critical
>
> I found this issue in the TabletServer code, where for certain operations (chop, compact, flush, flushTablet, getActiveCompations, getActiveScans, halt, loadTablet, and unloadTablet), the RPC user's permissions are checked (and they are expected to be the system user), and if they aren't correct, the TabletServer will simply voluntarily kill itself. This is a problem, because the TabletServer assumes it is the problem, instead of the incoming credentials.
> The Master may rely on this behavior to force tablets to be unloaded if a TServer is bad. However, it should probably just try to delete the lock in zookeeper instead. After all, if it can delete the lock in zookeeper, it has the correct configuration, and it can be assumed that the TServer is the one that is wrong.
> (see o.a.a.server.tabletserver.TabletServer.checkPermission())



--
This message was sent by Atlassian Jira
(v8.3.4#803005)