# Source: https://docs.oxla.com/security/access-control.md

> ## Documentation Index
> Fetch the complete documentation index at: https://docs.oxla.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Access Control

## Overview

Oxla implements role-based access control (RBAC) features, including roles, privileges
and ownership. These features function similarly to those found in other leading database systems,
providing a familiar access control model for users and administrators.

## Enabling Access Control

Access control is enabled by default on new Oxla installations. You can disable access control through the configuration file if needed.
For detailed instructions on configuring access control, refer to the Oxla
<a href="/configuration-deployment/configuration/oxla-configuration-file" target="_blank">Configuration File</a> documentation.

The access control (AC) behavior is as follows:

* If the access control flag is explicitly set in the configuration file, that setting is always followed
* If the flag is not explicitly set in the configuration:
  * When Oxla Home is empty, AC will be **enabled** by default
  * When Oxla Home is non-empty, AC will be **enabled** only if it was previously enabled

<Note>
  For backward compatibility, old Oxla versions did not have access control (AC).
  If you use a new Oxla release with an Oxla Home created by these old versions, AC will be **disabled** by default.
  However, if the Oxla Home comes from an older where AC was likely enabled, then AC will be **enabled** by default.
  This behavior helps maintain security settings appropriate to the Oxla Home’s history.
</Note>

## Default Superuser

Oxla always includes a default superuser account named `oxla` with the initial password `oxla`.

* During the first startup, you can set a custom password for the default superuser using the `access_control.initial_password` parameter in the configuration file
* After setting the password, you can remove this parameter from the configuration
* You can also change the password later using the <a href="/security/roles#changing-password" target="_blank">ALTER ROLE</a> query

<Tip>For security reasons, it is highly recommended to change the default superuser password immediately after installation.</Tip>

## System Catalogs Visibility

Users can view rows in system catalog tables only if those rows correspond to objects or reside in schemas to which the user has access.
For example, in the `information_schema.tables` table, a user can see all tables for which they have any grants,
as well as all tables in schemas where they have the `USAGE` privilege.

## Restrictions

* Only superusers have the `SELECT` privilege on internal system tables
* Privileges on internal system tables cannot be granted or revoked
* Only superusers and database owners can create new schemas
* Only superusers can create new roles
* Every role is granted the `CONNECT` privilege to the default database at creation (this privilege can be revoked)
* Every role is granted the `USAGE` privilege on the default `public` schema at creation (this privilege can be revoked)
* Oxla does not support role membership, so **privilege inheritance** is not available

<Info>Once access control is enabled and Oxla Home is not empty, you cannot disable access control.
If you attempt to run Oxla with the access control flag in `OXLA_HOME` set to `OFF` after it was previously enabled,
Oxla will enter a <a href="/troubleshooting-optimization/degraded-state-handling" target="_blank">**degraded state**</a>.</Info>