Internal error returns during authentication after grant/revoke component priv

[Paul Low]

The following is returned during authentication for a valid user:

*** ERROR[8837] Internal error occurred. User: TRAFODION

This seems to happen after component privileges are granted/revoked in a previous session.

To reproduce the problem you could do the following:

Log on to the system as yourself, then switch to trafodion.
Revoke the privilege in sqlci: revoke component privilege show on sql_operations from "PUBLIC";
Try to connect through ODBC/JDBC from your client. The error should occur.

More details can be found in email thread. I have not included it here since there are system info and passwords everywhere. Let me know if you need more details. Here is a summary:

... was again reporting internal errors on <cluster>. I really think this is because we authenticate as one user say <user1> and in next session try to access the metadata as that user ( even if it is for the same user <user1> or Trafodion ). This raises error 4481 leading to internal error.

Should we be resetting the id back to DB__ROOT after each disconnect ? or is there some other solution ?

[Paul Low (paul-low-x)]

Changing case severity from High to Critical. Other QA members are seeing same internal error during testing with security enabled. They are not granting/dropping component privileges as far as I know.

[Weishiun Tsai (wei-shiun-tsai)]

This is a test stopper as trafci would hang with this error. We tried several times to run SQL regressions with security turned on to no avail. This problem would simply cause the tests to hang.

[Weishiun Tsai (wei-shiun-tsai)]

And the hang happened at the trafci connection time:

-bash-4.1$ trafci.sh -h <ip>:<port> -u <user> -p <password>

Welcome to Trafodion Command Interface
Copyright(C) 2013-2014 Hewlett-Packard Development Company, L.P.

Host Name/IP Address: <ip>:<port>
User Name: <user>

*** ERROR[8837] Internal error occurred. User: QAUSER_USER [2015-04-01 16:32:28]

User Name:

[Cliff Gray (cliff-gray)]

The problem is due to metadata no longer selectable by all users. When an MXOSRVR is returned to the pool, the context is the ast user to logon successfully. If this is not DB__ROOT (or a user with SELECT privilege on the AUTHS table), authentication fails ith a privilege error, which is translated to internal error for the user.

The long term fix is for MXOSRVR to have a DB__ROOT context it can switch to while in the pool. The short term fix is to enable internal query during authentication to allow the select from the AUTHS table to succeed.

[Cliff Gray (cliff-gray)]

Fix was delivered in change 1429.

[Paul Low (paul-low-x)]

Verified on build 0410