cliff gray <> in Trafodion

Security bug fixes

Corrects a number of bugs in security and SQL DDL.

1. 1439316: Internal error when creating view with sequence.

2. 1441825: User in role-owned schema is not given grant option.

3. 1447328: DB__ROOT required to revoke component privileges

by other users.

4. 1447330: DB__ROOT required to revoke object and

column privileges granted by other users.

In addition, Launchpad bugs 1350627 and 1438886 were tested and

found to no longer be a defect.

Two new component-level privileges were added, MANAGE and


Users who have the MANAGE_PRIVILEGE component-level privilege can

grant and revoke privileges at the schema, object, and column

level on behalf of other users and roles. Users who have the

MANAGE_PRIVILEGE component-level privilege can also grant

"WITH GRANT OPTION" any privilege they have.

A user granted the MANAGE privilege has all the MANAGE_* privileges,



Change-Id: I10873de95f75114b937e1144f3af9aba76884eae

    • -46
    • +25
    • -97
    • +70
Column-level privileges - part 2

Support for column-level privileges will be in multiple deliveries.

This delivery add the following portions:

1. DML operations (SELECT, INSERT, UPDATE) now recognize granted

column-level privileges.

2. CREATE VIEW now recognizes granted column-level privileges.

3. Revoke of object-level privileges now revokes the corresponding

column-level privilege.

Missing functionality:

1. Privileges can be granted to roles and revoked from roles, but

REVOKE ROLE does not consider column-level privileges when


if an object depends on a role's granted privileges.

2. Column-level revoke does not enforce RESTRICT, i.e., privileges

may be revoked even if there are dependent privileges.

3. ALTER TABLE DROP COLUMN does not remove associated column-level

privileges, nor does it check for dependent objects.

Change-Id: Ieba04c77edb945dfeb1994e9949b54072289465e

    • -18
    • +101
    • -2
    • +752
    • -47
    • +184
    • -28
    • +119
    • -71
    • +234
Column-level privileges

Support for column-level privileges will be in multiple deliveries.

This delivery add the following portions:

1. Creation of the metadata table COLUMN_PRIVILEGE.

This table is created when the INITIALIZE AUTHORIZATION command is run.

Existing privileges are preserved, but warnings are issued referring to

existing metadata tables. An UPDATE option will be added later.

2. Granting of column-level privileges

Full support is present for granting column-level privileges.

Privileges can be added and updated for one or more columns on a table or view.

Support for WITH GRANT OPTION is coded, though not enabled until WITH GRANT

OPTION is enabled at the object level.


The SHOWDDL command displays column-level privileges. Regardless of

the order the privileges were granted, SHOWDDL displays them in column

order, and within each column, in the order they appear in the bitmap


4. Revoking of column-level privileges

Only partially implemented. The basic operation of revoking granted

column-level privileges and grant option for is implemented. All

relevant security checks are performed. GRANTED BY is not implemented.

RESTRICT and CASCADE options are not supported. Hence, any dependent

objects remain when column-level privileges are revoked.

Missing functionality

In addition to column-level revoke only be partially implemented,

here are other items not present in this delivery:

1. Privileges can be granted to roles and revoked from roles,

but REVOKE ROLE does not consider column-level privileges when

determining if an object depends on a role's granted privileges.

2. Similarly, revoke at the object level does not consider

column-level privileges that may allow an object to remain after

an object-level privilege is revoked.

3. CREATE VIEW does not consider column-level privileges

when determining if the user has authority on the referenced

tables and views.

4. Run-time DML operations do not considered column-level when

determining if the user has authority to perform the query.

Change-Id: Icd3db88708d1e0ae7e9236e10b2a760bba287155

    • -0
    • +520
    • -23
    • +25
    • -44
    • +44
    • -0
    • +408
    • -129
    • +554
  1. … 3 more files in changeset.
Drop view that references a sequence generator

Fixes a problem where a view that referenced a sequence generator

could not be dropped. Code handling objects referenced by views

was not prepared for sequences. Launchpad bug 1439319.

There are many other problems related to views referencing

sequences (e.g. see 1439316); this change only

corrects the problem of not being able to drop the view.

Change-Id: I8fbb8cbf565f9e6eef649152a0cec8e85d73afa4

Authentication internal error

Launchpad bug 1438856 reports an internal error when logging

on to Trafodion. The problem is due to metadata no longer

selectable by all users. When an MXOSRVR is returned to the

pool, the context is the last user to logon successfully. If

this is not DB__ROOT (or a user with SELECT privilege on the

AUTHS table), authentication fails with a privilege error,

which is translated to internal error for the user.

The fix is to enable internal query during authentication

to allow the select from the AUTHS table to succeed.

Change-Id: I7a02cb6ae6742e65d99771913843d949126dd948

    • -4
    • +34
DROP SCHEMA CASCADE and other fixes

Corrects a problem (Launchpad bug 1435967 and 1437474) with DROP

SCHEMA CASCADE when a view is defined that references a UDF in

the schema.

Corrects a problem where DB__ROOT could not grant privileges on

objects owned by DB__ROOT except for tables and views.

Corrects a problem where histogram tables in shared schemas were

owned by the first user to run update statistics; the tables

are now owned by the schema owner regardless of which user runs

the UPDATE STATISTICS command first.

Change-Id: I3289d456ac0d1fdd3d7923892395ddf9229e47bf

    • -0
    • +10
Correct security keys generated for REVOKE ROLE

Launchpad Bug 1392086: DML commands continued to succeed after

REVOKE ROLE command removed privilege.

DML commands will now report an error if a REVOKE ROLE command

results in the user no longer having the requisite DML privilege.

Previously incorrect QI security keys were generated and the

query would succeed until the session was restarted.

Change-Id: I2df4fb922c86e36f8989537d3475385a912b08dc

Updated EXPECTED file

The expected file for Catman1 test 138 needs to be updated after


Change-Id: I75ae8fda3e7a5306c310c70f31a15b58c82620c7


Support for UDFs was added early in Trafodion, but a few DDL

and security problems still existed:

o DROP FUNCTION RESTRICT does not fail when the UDF

is referenced by a view

o DROP FUNCTION CASCADE does not drop referencing views

o References to undefined UDFs resulted in 4 error messages,

one of which referenced the NEO catalog

o REVOKE and REVOKE ROLE do not check for dependent views

when revoking EXECUTE from a UDF

All of these are addresses in this delivery except for

REVOKE of the EXECUTE privilege from a UDF that is

referenced by a view.

There was also a problem with indirect references to UDFs

not checking security, but that was corrected as part of

change 1177 that this change is built upon.

In addition, a recent change to prohibit unauthorized access

to metadata resulted in all SHOWDDL commands no longer working

for non DB__ROOT users.

DROP SCHEMA CASCADE did not drop sequence generators

not associated with a table.

Change-Id: I419334f5f33625f6aa0a0bcb70214ac181ba5cdf

    • -1
    • +1
    • -1
    • +60
SHOWDDL, QUERY Cancel, rework

This delivery addresses security issues with SHOWDDL, adds initial

support for security in query cancel, and implements part of the

proposed GIVE commands.

Bug 1414234: SHOWDDL command now check component privileges.

SHOW is granted to PUBLIC by default, so effectively there are

no new restrictions unless SHOW is revoked from PUBLIC.


SHOWDDL ROLE now checks for MANAGE_ROLES or SHOW privilege.

SHOWDDL SCHEMA now checks for SHOW privilege.

SHOWDDL USER now checks for MANAGE_USERS or SHOW privilege.

SHOWDDL LIBRARY is implemented. A user must have the USAGE

privilege on the library, or the MANAGE_LIBRARY or SHOW privilege.

New function to determine if the user canceling the query has

the authority: either DB__ROOT, or the user owns the query, or

the user has the QUERY_CANCEL privilege. Note, the code is

delivered in an inactive state pending future integration.

Three new component privileges are added: QUERY_ACTIVATE,

QUERY_CANCEL, and QUERY_SUSPEND. These will be added if

authorization is dropped and reinitialized. A future


command that will add these privileges to an existing

instance with authorization enabled.

Support for library objects was added to NATable, but the code

is currently not used. May be integrated into CREATE ROUTINE

and GRANT for libraries in the future.

Also included is minor rework from delivery 1082, and the

GIVE SCHEMA command now updates associated privileges when object

ownership is changed. Note, GIVE commands are still prototype.

A detailed blueprint for GIVE will be released shortly.

This patch merges with changes from 1177 and addresses a couple of

minor comments from the initial submittal.

Change-Id: I60419228f886555ed0e066441bb824c5246ee498

  1. … 14 more files in changeset.
The following Launchpad bugs are fixed in this change:

Bug 1370749: Now using MAX_USERNAME_LEN instead of hardcoded value

Bug 1413760: CREATE TABLE LIKE was failing in some circumstances because

SHOWDDL was including the BY clause. Ownership rules changes in

CREATE TABLE changed when ANSI schemas was implemented, so the BY clause

is no longer needed.

Bug 1392107: Privileges granted on a view are no longer lost if the

view is replaced via CREATE OR REPLACE VIEW.

Bug 1370740: A potential memory corruption problem is now avoided

by reworking the authorization name lookup functions.

Bug 1413767: Previously DROP SCHEMA CASCADE would fail to drop a

table with an IDENTITY column.

Bug 1413758: Previously DROP TABLE CASCADE did not drop nested views.

Bug 1412891: Previously DROP TABLE CASCADE failed if a dependent object

contained a delimited name.

Changes are present for 1392086, but the work is not yet completed.

This problem is related to roles and security keys.

Code changes are also present for giving ownership of an object to

another authorization ID, but these changes are not complete. A

description of

the changes is included.

The GIVE command transfers ownership of a SQL item from one

authorization ID to another. Implemented in this delivery is


GIVE ALL transfers all SQL items owned by an authorization ID to another

authorization ID. Current or new owner can be a user or a role. The

GIVE ALL command requires the ALTER privilege.


GIVE SCHEMA behavior depends on the type of schema and whether RESTRICT

or CASCADE is specified. For private schemas, all the objects in the

schema are given, as well as the schema itself. For shared schemas,

only the

schema is given, unless the CASCADE option is specified. In that case,


of all the objects in the shared schema is given to the new owner. Use


the CASCADE option requires the ALTER_SCHEMA privilege. Otherwise, GIVE

SCHEMA only requires the user to be the owner of the schema.


NOTE: RESTRICT and CASCADE are not applicable to private schemas and are


GIVE OBJECT is added to the syntax but is not implemented and may not

be implemented.

A more detailed blueprint will be provided prior to the final delivery

of GIVE.

Change-Id: I7449da599dc80de1c0659164e684841cda4647c8

    • -0
    • +272
  1. … 20 more files in changeset.

DROP SCHEMA CASCADE now drops all libraries, functions, procedures, and

sequence generators ina schema. Previously only tables, views, and

indexes were dropped.

DROP TABLE CASCADE and DROP VIEW CASCADE now drop dependent views

located in schemas other than the schema containing the table or

view being dropped.

DROP LIBRARY now supports the CASCADE option, and drops any dependent

functions or SPJs (procedures).

This delivery fixes Launchpad bugs 1350540 1353757 1392081 1393888

Change-Id: I029b9579f81ce7472560dd1c490fab8410141805

    • -48
    • +11
    • -7
    • +55
    • -46
    • +118
    • -14
    • +14


schema to be created was not a regular identifier. Now

names are delimited.

Also fixed a REVOKE ROLE problem where an unitilized variable

could lead to a core.

Updated HIVE tests to include CREATE SCHEMA commands.

Change-Id: I90572addc8c00d77fb9a736e165cd3e8d8b420f2

    • -3
    • +30
ANSI Schema changes

ANSI Schema

Implements the changes to support ANSI schemas. For more information

see the blueprint at:

The syntax changes for REGISTER USER and CREATE ROLE were not

implemented in this delivery.

NOTE: This code was reviewed internally prior to merging with the

main branch.

Change-Id: I1c7937dbcd067e792dcacb65f12c43e4f84a25ad

Change-Id: I98395eeef1e8bde424d9e83f96928358f0b1991b

    • -0
    • +116
  1. … 61 more files in changeset.
Set authorization enabled/Sequence generator privs

Code to set authorization enabled at startup

Contains changes to check authorization at process startup time and

code review comments from previous deliveries

Description of changes to check authorization at process startup time:

At process && compiler context startup time a check has been added to

see if authorization is enabled. Based on this check a new flag is set

in the compiler context.

Any operation wishing to see what the authorization status is, just need

to look at this flag.

This code has been reviewed internally by the security team.

There will be a subsequent set of changes in the PrivMgr code to return

better errors.



Added a new flag containing authorization status and methods that get

and set this flag.


In method: NADefaults::readFromSQLTables added code that checks to see

if authorization is enabled and sets the flag in CmpContext.

It calls CmpSeabaseDDL::isPrivMgrMetadataInitialized to determine

privmgr metadata status


Implementation of method isPrivMgrMetadataInitialized

Changed isAuthorizationEnabled to look at the CmpContext flag instead of

the flag (which was removed) in the CmpSeabaseDDL class

Changed initSeabaseAuthorization and dropSeabaseAuthorization to change

the flag in the context and kill compiler processes

Changed all calls to PrivMgrnnnn::isAuthorizationEnabled to use the

CmpSeabaseDDL::isAuthorizationEnabled or directly from CmpContext

Bin/SqlciErrors.txt & sqlcomp/CmpDDLCatErrorCodes.h to create a new

error 1234 (currently unused)

Sqlcomp/PrivMgrMD.cpp changed mapping of PrivMDStatus to match what was

done in nadefaults.cpp

Optimizer/BindRelExpr.cpp && sqlcomp/nadefaults.cpp to look in

CmpContext for authorization enabled flag

Check privileges for Sequence generator

Adds the code in compiler to check for usage privilege

for any sequence generators used in a query.

Additional privilege checks, plus

This delivery includes:

Verifying that user had correct privileges to perform all DDL

operations. This is performed through a call to

isDDDLOperationAuthorized. The signature changed to pass the object

owner instead of the object name. This eliminates an I/O and made the

method simpler. All callers were changed to use the new signature and

all DDL operations now call this method after the NATable structure has

been retrieved. A new regression test was added (TEST138).

As part of DDL privilege checking, the ALTER and DELETE component

privilege is no longer granted during initialize authorization.

Updated files to address code review checkin for change ID:


Fixed a problem where SHOWDDL was not returning an error when user does

not have appropriate privilege.

Made the PRIVMGR_MD schema a reserved schema.

Added code to switch contexts for several PrivMgr operations. This

required a change to not grant owner privileges when creating the


Added a KNOWN diff file for TEST133. There is an issue where rows are

not being loaded into OBJECT_PRIVILEGES during an error test.

Change-Id: I7448e7171e5f1f09feb6d1f688470b72dc1f43d4

    • -0
    • +25
    • -37
    • +21
    • -0
    • +1525
    • -0
    • +308
  1. … 12 more files in changeset.
DBSecurity: REVOKE ROLE, credential propagation, +


1) Corrects a CLI/Executor overwrite problem and removes workaround

code in PrivMgr. Launchpad bug #1371176.

2) REVOKE ROLE now lists referencing and referenced objects when a

revoke request is refused due to dependencies.

3) REVOKE ROLE now reports that the specified grant cannot be found

when grantor has not granted the role to the user. Previously the

misleading error "Not Authorized" was issued, which as confusing when

the user was DB__ROOT. The same change was made for REVOKE COMPONENT

PRIVILEGE. A similar change will be made in the future for revoking

object privileges.

4) REVOKE ROLE now considers grants to PUBLIC before concluding a

revoke would require a dependent object to be dropped.

5) User credential are now propagated to the the compiler process.

Launchpad bug 1373112.


If the priv/role, grantee, grantor tuple does not exist, REVOKE

ROLE/REVOKE COMPONENT PRIVILEGE now reports error 1018: Grant of role or

privilege <name> from <grantor> to <grantee> not found, revoke request


When REVOKE ROLE detects a dependent object, error message 1364 now

reports the referencing and the referenced object.

Cannot revoke role <role-name>. Object <referencing-object> depends on

privileges on object <referenced-object>.

Details for user credential propagation:

The propagate user credentials code has only been partially implemented.

The existing code sends the user ID to the first compiler process.

Other compiler processes started would not get the connected user ID

instead the DB__ROOT user ID became the user by default. Therefore,

privilege checks are succeeding when they should fail.

User credentials consist of an integer user ID and a username. The

existing code only passed the user ID. The compiler process would

then do a metadata look-up to get the username. If we kept this

model, then we would get into an infinite loop:

When the compiler process received the user ID, it did a

metadata read to get the associated username. After reading the

metadata, both the username and user ID was set in context globals.

The metadata lookup code will start another arkcmp process for the

compilation request. The compilation would then start a compiler

process. That compiler process would start another compiler process,


The solution is to send both the username and user ID to the compiler

process. Both values are known at the time the compiler process is

started. This alleviates the need for a database look-up when the

compiler process starts. To do this a new session attribute was

created - SESSION_DATABASE_USER. This session attribute sends both the

user ID and username to the compiler process during startup processing.

Once we were able to start a compiler process and store a user ID other

than DB__ROOT in the Context globals, another similar infinite loop

occurred during privilege checking. For example, a showddl command

starts a compiler process when extracting privilege information. The

compiler calls checkPrivileges to make sure the current user has

privileges. The checkPrivileges statement makes a metadata request

that requires a compilation. This starts up another compiler process.

This compiler process is sent the metadata request. When compiling the

metadata request in the new compiler process, checkPrivileges is called

which starts a compiler process, …

This worked previously because the user passed was DB__ROOT, and the code

in checkPrivileges is short circuited and the metadata call is avoided.

A fix to set the parserflag (INTERNAL_QUERY_FROM_EXEUTIL) before the

metadata request was performed. This fix requires that the file

"SqlParserGlobalsCmn.h" be included in additional files. Including this

file needs to be done with care. In order to get everything to compile,

we changed where this file was included in several places.

Once all these changes were made, the envvar: DBUSER_DEBUG now works.

If set, then good details about how users are sent to different

processes is displayed.

Change-Id: If7538eee38178c2345fe418172c6196b25a20b33

  1. … 16 more files in changeset.
Interim DBSecurity deliver for December

Change-Id: Iff416cea17286bc580409f5e00641cfa54820252

Interim DBSecurity deliver for December

1) Implement REVOKE ROLE RESTRICT. Previously dependent objects were

not detected. Launchpad bug #1370739.

2) REVOKE ROLE with a list of grantees would fail for all grantees after

the first. Now works for the entire list. Launchpad bug #1375494.

3) SHOWDDL ROLE now shows the GRANTED BY clause if the grantor is not

DB__ROOT. Launchpad bug #1374586.

4) Component privilege names can now be reserved names. Launchpad bug

5) Added tests to catman1/test135 for privileges and RI constraints.

6) Added support for REVOKE RESTRICT for RI constraints.

7) Added support for USAGE privilege for sequence generator.

This code has been reviewed by the database security team but additional

input is encouraged and welcomed.

Change-Id: I88266fca6d13d6852f046e553ba3505ff878b7f8

    • -1
    • +709
    • -95
    • +145
    • -96
    • +111
    • -9
    • +61
  1. … 15 more files in changeset.
PrivMgr code review rework/fixes

This code has been reviewed and/or tested by some of the members of the

security team.


1) Replaced calls to sprintf with calls to std::to_string. This avoids the

problem of the buffer potentially being too small for the written data.

2) Eliminated use of STATUS_INTERNAL error return in PrivMgr code. Usage was

inconsistent and could lead to confusion and errors. Internal errors are

now reported as STATUS_ERROR.

3) Previously construction of internal errors was not supplying the filename.

Two defines were created, one for PrivMgr (PRIVMGR_INTERNAL_ERROR) and one

for SeabaseDDL (SEABASEDDL_INTERNAL_ERROR) to generate the error completely,

using the provided string.

4) Code was aligned where previous changes had left it misaligned.

5) The command GET COMPONENT PRIVILEGES ON component FOR authID was

implemented. Also, the header for the related GET COMPONENT PRIVILEGES ON

component was updated.

6) ALTER USER now supports remapping the DB__ROOT user. Also, the command

now correctly checks the REMAP_USER privilege.

7) Checks for ID/Name mapping were not always checking the return code.

Checks were added and errors (sometimes internal) were added.

8) Buffer size for usernames was previously hardcoded, now


9) DROP ROLE now checks for granted privileges prior to removing the system

grant for the role.

10) GRANT/REVOKE ROLE now support the MANAGE_ROLES privilege for using the

GRANTED BY clause. Now a non-DB__ROOT user can grant or revoke a role on

behalf of another user, but only if they have the MANAGE_ROLES privilege.

This authority may be moved to a separate privilege in the future.

11) A member variable (myTable_) was not being freed in the destructor.

12) GRANT/REVOKE ROLE is now checking the return from insert, delete, and

update operations.


Previously error messages 1356 and 1357 were missing a parameter.


*** ERROR 1356 *** Cannot create the component privilege specified.

Component privilege code for the component already exists.

is now:

*** ERROR 1356 *** Cannot create the component privilege specified.

Component privilege code CR for the component already exists.

Error 1357 reports an existing component operation name.




Only change is alignment changes from a previous review.



o Fixed the getComponentPrivilegesForUser query-missing a parenthesis.

o Updated the headers generated for GET COMPONENT PRIVILEGES ON component and


o Within the work() function, corrected code for handling dual GET COMPONENT

PRIVILEGES command based on presence/absence of param1 (authID).



Reverted component operations back to component privileges for use in dual







o verifyAuthority() in the base class was removed, and the version in the user

class was enhanced to support verifying the authority to remap users.

o Internal errors are now generated using the SEABASEDDL_INTERNAL_ERROR define.

o CmpSeabaseDDLuser::alterUser now supports remap the external username for

DB__ROOT. Previously reserved names were prohibited by the ALTER USER

command, now an exception is made for DB__ROOT if the operation is setting a

new external name.

o CmpSeabaseDDLrole::dropRole now checks for privileges granted to a role

before removing the system grant of the role. Previously the system grant

could have been removed leaving the role ungrantable.


o Internal errors are now generated using the SEABASEDDL_INTERNAL_ERROR define.

o grantRevokeSeabaseRole() now uses the MANAGE_ROLES privilege to determine if

a user can grant or revoke a role on behalf of another user. Previously

this was restricted to DB__ROOT. This authority may be moved to a separate

component privilege in the future.



o Replaced usage of STATUS_INTERNAL with STATUS_ERROR.

o Removed unused grantRoleToCreator() - CREATE ROLE calls PrivMgrRoles class



o Member variable myTable_ is now deleted when the instance is freed.

o Corrected generation of error message for existing component name or code to

use the correct parameter constructor type.

o Internal errors are now generated with PRIVMGR_INTERNAL_ERROR define.

o UIDToString (which calls std::to_string) used instead of sprintf to convert

component UIDs to strings.


o Member variable myTable_ is now deleted when the instance is freed.

o Internal errors are now generated with PRIVMGR_INTERNAL_ERROR define.

o UIDToString (which calls std::to_string) used instead of sprintf to convert

component UIDs to strings. Similarly, authIDToString is called to convert

granteeIDs and grantorIDs to strings.

o grantPrivilege() no longer removes WITH GRANT OPTION when a privilege a user

has WITH GRANT OPTION is re-granted to the user without WITH GRANT OPTION.

Instead, the grant is now a nop.


o Internal errors are now generated with PRIVMGR_INTERNAL_ERROR define.

o UIDToString (which calls std::to_string) used instead of sprintf to convert

component UIDs to strings.


Removed STATUS_INTERNAL from the list of PrivStatus enums.



o Added static inline functions authIDToString and UIDToString. Respectively

they take an int32_t and int64_t and return a std:string. Internally they

both cast the value to long long int as that is the only equivalent type

supported by the current (4.4.6) gcc compiler.


o Internal errors are now generated with PRIVMGR_INTERNAL_ERROR define.

o UIDToString (which calls std::to_string) used instead of sprintf to convert

component UIDs to strings.

o A grant of select to the AUTHS table to PUBLIC was removed. This was added

as a workaround, but another workaround (allow SELECT on all metadata tables)

superseded this one.


o Internal errors are now generated with PRIVMGR_INTERNAL_ERROR define.

o Checks for STATUS_INTERNAL were removed.


o Member variable myTable_ is now deleted when the instance is freed.

o Internal errors are now generated with PRIVMGR_INTERNAL_ERROR define.

o authToString is called to convert roleIDs, granteeIDs, and grantorIDs to strings.

o grantRole() no longer removes WITH ADMIN OPTION when a privilege a user has

been granted a role WITH ADMIN OPTION and the role is re-granted to the user

without WITH ADMIN OPTION. Instead, the grant is now a nop.

o The error return from insert or update is checked following a grant as well

as from delete and update following a revoke, and an internal error is

reported if the operation fails.

Change-Id: I6d9fc31455222f28cdc5d0db65dc75fc8bb4a99e

    • -91
    • +75
    • -164
    • +154
    • -10
    • +13
    • -37
    • +14
    • -101
    • +58
Corrects problems w/authetication error reporting

1) Error not reported when authentication fails (LP 1321059)

2) Authentication error reporting should be moved out of CLI (US


In addition, the template authentication configuration file refers to

the wrong script for enabling authentication. (LP 1327302)

Analysis and Design:

When support for Zookeeper was added to MXOSRVR, authentication was not

active. The code to retrieve and handle errors was moved later in the

connection logic. Unfortunately, by the time it was invoked, the error

was no longer available, and a generic error was reported by an

exception handler. The check is move back to its previous location.

Previously the CLI would load authentication error codes and text into

the diags area, and then MXOSRVR would extract it. Now, MXOSRVR simply

generates its own error, although currently it looks a lot like the old

error (minus the CLI reference).

After the authentication configuration template was delivered, the name

of the script to enable authentication was chosen. The template was not

updated due to time constraints.


Previously the error messages from authentication were of the form:

*** ERROR[8837] CLI Authentication : User: external-username : invalid

username or password

The new format is:

*** ERROR[8837] Invalid username or password. User: external-username

The format of this message will likely change, but for now the original

CLI range error is retained.

Change-Id: I8ab58404941aaf50319883071bb4142cbaafb557

    • -22
    • +30
    • -6
    • +2
    • -3
    • +1
    • -27
    • +69