[CBRD-25268] Refactor authenticate module

[hgryoo]

http://jira.cubrid.org/browse/CBRD-25268

This PR refactors authenticate.c file into serveral files according to the following code analysis.

Background

Terms (Authenticate, Authorization)

CUBRID's Authenticate module handles authentication and authorization processing for users and database objects. Two key concepts related to this are:

• Authentication: The process of verifying a user's identity.
• Authorization: Granting and controlloing user access to system resources based on authentication.

Specifically, CUBRID is responsible for the following functionalities:

• Authentication: Managing users (CRUD) and verifying credentials (password) during user login.
  • Login
    • Password
• Authorization
  • User CRUD
  • Grant, Revoke
  • Check authorizations

System Catalogs

In CUBRID, information related to user management and database object privileges is managed through system catalog tables.

The database objects that can be assigned privileges, their system catalog names, and a brief description are as follows:

• Database Objects
  • Table, View (_db_class): As of version 11.3, these are the smallest units to which database access permissions can be granted. Access is allowed for the owner and users who have been granted permissions.
  • Trigger (db_trigger): Has access permissions dependent on the associated table. The owner can modify/delete the object. It runs with owner privileges.
  • Index (_db_index): Has access permissions and creation permissions dependent on the associated table.
  • Serial (db_serial): All users have access permissions. The owner can modify/delete the object.
  • Synonym (_db_synonym): All users have access permissions. The owner can modify/delete the object.
  • Server (_db_server): All users have access permissions. The owner can modify/delete the object.
  • Stored Procedure (_db_stored_procedure): All users have access permissions. The owner can modify/delete the object. As of version 11.3, it runs with caller privileges.

💡 The DBA has the same permissions as the owner for each database object.

The followings are the system catalogs that manage user and password information, as well as granting information.

• User (db_user)
• Password (db_password)
• Database Object-specific granting information (_db_auth)
  • {grantor, grantee, grant_type ...}
• User-specific granting information (db_authorization)
  • {user, set of _db_auth rows}

For more details of schema information for each system catalog, refer to the CUBRID manual.

💡 As of version 11.3, _db_auth and db_authorization manage granting information for tables and views (_db_class) only. Other database objects are only supported for owner changes. In version 11.4, privilege assignment will be expanded to other objects beyond tables and views.

Overview

• createdb builds system catalogs related to user and granting information in cub_server.
• unloaddb exports user and granting information.
• cubridcs and cubridsa handle authentication and authorization for database resources (objects).

Architecture

• At the top level, unloaddb, createdb, cubridcs, and cubridsa use different entry point APIs of the authenticate module.
  • createdb: Calls au_install() to build the related system catalogs. createdb is a SA_ONLY utility that performs database creation through the client-side logic of the SA library.
  • unloaddb: Reads user and granting information and writes it as text (CUBRID's unloaddb form) for migration.
  • cubridcs, cubridsa: Use key features like login, authentication, and authorization by connecting to cub_server through utilities like csql, cub_cas, and CS utility.
• authenticate_context: Handles user login and holds environment information for authentication/authorization of the currently connected user.
• authenticate_cache: Memory cache to prevent meaningless repetitive catalog information access/changes in runtime. Also used for memory representation of relevant information.
• authenticate_owner: Collection of routines to handle owner changes for database objects (user-based authorization).
• authenticate_grant: Processes grant/revoke statements. Provides the following two APIs to either retrieve complex join relationships in memory representation (authenticate_cache) or apply changes in the cache to the system catalog.
  • get_grants()
  • apply_grants()
• authenticate_access_XXX: CRUD processing for each catalog schema.
• authenticate_migration: Routine processing for migrating user and grant information using unloaddb.

Structures and APIs

The following is an introduction to the key data structures and APIs of the authenticate module.

• Note that cubridcs, which includes the authenticate module, is a single-threaded structure, meaning most of the called APIs are not thread-safe.
• The authenticate module primarily accesses system catalogs to generate the necessary information and handles the OIDs and values of the relevant data. Further details are explained in the following content.

Key Variables (OID)

System Catalog Class OIDs

• MOP Au_authorizations_class: Class OID of db_root
• MOP Au_authorization_class: Class OID of db_authorization
• MOP Au_user_class: Class OID of db_user
• MOP Au_password_class: Class OID of db_password

OIDs of Records in System Catalogs

• MOP Au_root: Unique instance (row) OID of db_root (∈ db_root)
• MOP Au_dba_user: OID of the DBA user (∈ db_user)
• MOP Au_public_user: OID of the PUBLIC user (∈ db_user)
• MOP Au_user: OID of the currently logged-in user (∈ db_user)

Operational Variables

• boolean Au_disable: Authorization check flag; if true (1), authorization checks are bypassed.
• char* Au_user_name: Name of the currently logged-in user.
• char* Au_user_password...: Encrypted password information of the currently logged-in user.
• authenticate_cache Au_cache: Memory cache of privilege information obtained by accessing the system catalog.

Key Functions

Lifecycle Functions

• au_init (void): Initializes key variables in memory. Does not fetch actual values from the DB server.

• au_install (void): Called by the createdb utility and creates the privilege-related system catalogs on the DB server as described above.

• au_start (void): Called by utilities like cubridcs or cubridsa, which include CAS, CSQL, and CS libraries. Fetches privilege-related information from the DB server into memory structures and performs login.

• au_final (void): Removes key variable information from memory.

  au_init() -->  au_install () --> au_start () --> tasks* --> au_final ()
       |                                 ^
       ---->        au_login ()      ----|
  

Authenticate Context Functions
The authenticate context holds comprehensive information managed by login and user status change APIs during runtime.

• set_user (user)

• set_password (user, password, ...)

• login (name, password, ignore_dba_priv)

• disable_password (void)

• Getters:

  • get_public_user(), get_dba_user(), get_current_user_name(), get_public_user_name(), get_user_class_name()

Authorization Functions

• au_grant ()
• au_revoke ()

Owner Access/Change Functions

• au_change_owner (DB_RESOURCE_TYPE, ): Changes the owner without considering inheritance or partitions.
• au_change_class_owner (): Changes the owner considering inheritance and partitions.
• au_change_serial_owner ()
• au_change_trigger_owner ()
• au_change_sp_owner ()
• au_get_class_owner ()

Migration Functions for unloaddb

• au_export_users ()
• au_export_grants ()

Debugging Functions

• au_dump (void)
• au_dump_to_file (FILE)
• au_dump_user (user, FILE)
• au_dump_auth (FILE)

[hyunikn]

Suggested change

	AU_DISABLE (dummy);
	Au_disable = true;

dummy is not used after this line and can be removed.

[hgryoo]

To hide Au_disable, I prefer to call AU_DISABLE (value).

[kisoo-han]

LGTM!!