Security fixes for 144553, 1414125, and 1393529 1445583: showstats command performance slow with security enabled
Several changes were made to improve performance:
Performance optimization: NATable.cpp: NATable::setupPrivs - If the current user is the object owner, then default the privilege bitmap to object Owner values - no need to call PrivMgr to get privileges
Caching optimization: We are now caching privmgr metadata tables in compiler cache when the compiler context is instantiated. This avoids a metadata lookup for these tables.
- Added new methods that return if the table is part of the PrivMgr schema - Adjusted CmpSeabaseDDL::createMDdescs to include privmgr metadata in the cached entries - Adjusted CmpSeabaseDDL::getMDtableInfo to check for privmgr metadata tables from the cached entries - Removed obsolete code CmpSeabaseDDL::alterSeabaseDropColumn - changed CmpSeabaseDDL::getSeabaseTableDesc to check for both system and privmgr metadata from compiler cache - added new method CmpSeabaseDDL::getPKeyInfoForTable that returns the primary key name and UID for a table. This is needed when dropping privmgr metadata tables
Removed extraneous recompilations of HISTOGRAM structures: Today, update statistics and showstats are reloading NATable entries for HISTOGRAM tables on every access. This is because the parserflag ALLOW_SPECIALTABLETYPE is turned on. When this flag is turned, the compiler always reloads the cache entries - see code from CmpMain::sqlcomp:
//if using special tables e.g. using index as base table //select * from table (index_table T018ibc); //then refresh metadata cache if(Get_SqlParser_Flags(ALLOW_SPECIALTABLETYPE) && CmpCommon::context()->schemaDB_->getNATableDB()->cachingMetaData()) CmpCommon::context()->schemaDB_->getNATableDB()->refreshCacheInThisStatement();
Changed code to not set ALLOW_SPECIALTABLETYPE and ALLOW_PHONYCHARACTERS parserflags by default. Individual statements are setting these flags as needed.
1414125: User without priv can view data in metadata tables
The problem is that a user with priv cannot view data in metadata tables. Even when a user had SELECT privilege on a system or privmgr metadata table, the request failed.
The problem is that parameter 2 sent to CmpDescribeIsAuthorized in hs_globals.cpp is NULL so SELECT priv is not checked. If the user has SHOW component privilege, it works. A call was added to getPrivileges for metadata tables before calling CmpDescribeIsAuthorized.
1393529: Core dump accessing MD table descriptors
When "UPDATE STATISTICS LOG [ON, OFF, CLEAR]" is specified by a non DB__ROOT user, a core dump occurred. This happens because the isAuthorized check is performed expecting a NATable structure. This command does not need any special security checks.
Updated traf_authentication_setup script to support a new installation option
Fix for bug 1442932 and bug 1442966, encoding for varchar Submitting this before finishing regressions on workstation, in the interest of time.
Key encodings for VARCHAR values used to put a varchar length indicator in front of the encoded value. The value was the max. length of the varchar and the indicator was 2 or 4 bytes long, depending on the length of the indicator in the source field. That length used to depend only on the max number of bytes in the field, for >32767 bytes we would use a 4 byte VC length indicator.
Now, with the introduction of long rows, the varchar indicator length for varchars in aligned rows is always 4 bytes, regardless of the character length. This causes a problem for the key encoding.
We could have computed the encoded VC indicator length from the field length. Anoop suggested a better solution, not to include the VC indicator at all, since that is unnecessary. Note that for HBase row keys stored on disk, we already remove the VC indicator by converting such keys from varchar to fixed char. Therefore, the issue happens only for encoding needed in a query, for example when sorting or in a merge join or union.
Description of the fix:
1. Change CompEncode::synthType not to include the VC length indicator in the encoded buffer. This change also includes some minor code clean-up.
2. Change the assert in CompEncode::codeGen not to include the VC indicator length anymore.
3. Changes in ex_function_encode::encodeKeyValue(): a) Read 2 and 4 byte VC length indicators for VARCHAR/NVARCHAR. b) Small code cleanup, don't copy buffer for case-insensitive encode, since that is not necessary. c) Don't write max length as VC length indicator into target and adjust target offsets accordingly (for VARCHAR/NVARCHAR).
4. Other changes in sql/exp/exp_function.cpp: d) Handle 2 and 4 byte VC len indicators in hash function and Hive hash function (problems unrelated to LP bugs fixed). e) Add some asserts for cases where we assume VC length indicator is a 2 byte integer.
CompDecode is not yet changed. Filed bug 1444134 to do that for the next release, since that change is less urgent.
Patch set 2: Copyright notice changes only. Patch set 3: Updated expected regression test file that prints out encoded key in hex.