Перейти к основному содержимому
Версия: 2.0.x

Часто задаваемые вопросы о привилегиях

Почему сообщение об ошибке "нет разрешения" все еще появляется, даже после того, как необходимая роль была назначена пользователю?​

Эта ошибка может возникнуть, если роль не активирована. Вы можете выполнить select current_role();, чтобы запросить роли, активированные для пользователя в текущей сессии. Если необходимая роль не активирована, выполните SET ROLE, чтобы активировать эту роль и выполнять операции с использованием этой роли.

Если вы хотите, чтобы роли автоматически активировались при входе в систему, роль user_admin может выполнить SET DEFAULT ROLE или ALTER USER DEFAULT ROLE, чтобы установить роль по умолчанию для каждого пользователя. После установки роли по умолчанию она будет автоматически активироваться при входе пользователя в систему.

Если вы хотите, чтобы все назначенные роли всех пользователей автоматически активировались при входе в систему, вы можете выполнить следующую команду. Эта операция требует разрешения OPERATE на уровне System.

SET GLOBAL activate_all_roles_on_login = TRUE;

Однако мы рекомендуем следовать принципу "наименьших привилегий", устанавливая роли по умолчанию с ограниченными привилегиями для предотвращения потенциальных рисков. Например:

  • Обычные пользователи могут установить роль read_only, которая имеет только привилегию SELECT, в качестве роли по умолчанию, избегая установки ролей с привилегиями, такими как ALTER, DROP и INSERT, в качестве ролей по умолчанию.
  • Администраторы могут установить роль db_admin в качестве роли по умолчанию, избегая установки роли node_admin, которая имеет привилегию добавлять и удалять узлы, в качестве роли по умолчанию.

Этот подход помогает гарантировать, что пользователям назначены роли с соответствующими разрешениями, снижая риск непреднамеренных операций.

Вы можете выполнить GRANT, чтобы назначить необходимые привилегии или роли пользователям.

Я предоставил пользователю привилегию на все таблицы в базе данных (GRANT ALL ON ALL TABLES IN DATABASE <db_name> TO USER <user_identity>;), но пользователь все равно не может создавать таблицы в базе данных. Почему?​

Создание таблиц в базе данных требует привилегии CREATE TABLE на уровне базы данных. Вам нужно предоставить эту привилегию пользователю.

GRANT CREATE TABLE ON DATABASE <db_name> TO USER <user_identity>;;

Я предоставил пользователю все привилегии на базу данных с помощью GRANT ALL ON DATABASE <db_name> TO USER <user_identity>;, но ничего не возвращается, когда пользователь выполняет SHOW TABLES; в этой базе данных. Почему?​

SHOW TABLES; возвращает только те таблицы, на которые у пользователя есть какие-либо привилегии. Если у пользователя нет привилегий на таблицу, эта таблица не будет возвращена. Вы можете предоставить любую привилегию на все таблицы в этой базе данных (используя, например, SELECT) пользователю:

GRANT SELECT ON ALL TABLES IN DATABASE <db_name> TO USER <user_identity>;

Приведенное выше утверждение эквивалентно GRANT select_priv ON db.* TO <user_identity>;, используемому в версиях до v1.5.2.

Какие привилегии требуются для доступа к Selena Web Console http://<fe_ip>:<fe_http_port>?​

Пользователь должен иметь роль cluster_admin.

Как изменился механизм сохранения привилегий до и после Selena v1.5.2?​

До v1.5.2, после того как пользователю были предоставлены привилегии на таблицу, привилегии сохранялись, даже если таблица была удалена и воссоздана. Начиная с v1.5.2, привилегии больше не сохраняются после удаления и пересоздания таблицы.

Как запросить пользователей и предоставленные привилегии в Selena?​

Вы можете получить полный список пользователей, запросив системное представление sys.grants_to_users или выполнив SHOW USERS, а затем запросить каждого пользователя отдельно, используя SHOW GRANTS FOR <user_identity>.

Каково влияние на ресурсы FE при запросе системных представлений о метаданных привилегий большого количества пользователей и таблиц?​

Когда количество пользователей или таблиц очень велико, запросы к системным представлениям sys.grants_to_users, sys.grants_to_roles и sys.role_edges могут занять много времени. Эти представления вычисляются в режиме реального времени, потребляя часть ресурсов FE. Поэтому не рекомендуется часто выполнять такие операции в большом масштабе.

Приведет ли пересоздание catalog к потере разрешений? Как следует резервировать и восстанавливать привилегии?​

Да. Пересоздание catalog приведет к потере связанных с ним привилегий. Вам следует сначала создать резервную копию всех привилегий пользователей, а затем восстановить их после пересоздания catalog.

Есть ли инструмент, поддерживающий автоматическую миграцию разрешений?​

На данный момент нет. Пользователи должны вручную резервировать и восстанавливать разрешения, используя SHOW GRANTS для каждого пользователя.

Есть ли ограничения на использование команды KILL? Можно ли ограничить её только завершением собственных запросов пользователя?​

Да. Команда KILL теперь требует привилегии OPERATE, и пользователь может завершать только те запросы, которые были инициированы им самим.

Почему предоставленные привилегии изменяются после переименования или удаления таблицы? Может ли система сохранить старые разрешения при добавлении разрешений для переименованной таблицы?​

Для нативных таблиц привилегии привязаны к ID таблицы, а не к её имени. Это обеспечивает безопасность данных, поскольку имена таблиц могут изменяться произвольно. Если бы привилегии следовали за именами таблиц, это могло бы привести к утечке данных. Аналогично, когда таблица удаляется, её разрешения удаляются, потому что объект больше не существует.

Для внешних таблиц исторические версии вели себя так же, как и внутренние таблицы. Однако, поскольку метаданные внешних таблиц не управляются Selena, могут возникать задержки или потери привилегий. Для решения этой проблемы будущие версии будут использовать управление разрешениями на основе имени таблицы для внешних таблиц, что соответствует ожидаемому поведению.

Как создать резервную копию привилегий пользователей?​

Ниже приведен пример скрипта для резервного копирования информации о привилегиях пользователей в cluster.

#!/bin/bash

# MySQL connection info
HOST=""
PORT="9030"
USER="root"
PASSWORD=""
OUTPUT_FILE="user_privileges.txt"

# Clear output file
> $OUTPUT_FILE

# Get user list
users=$(mysql -h$HOST -P$PORT -u$USER -p$PASSWORD -e "SHOW USERS;" | sed -e '1d' -e '/^+/d')

# Loop through users and get privileges
for user in $users; do
    echo "Privileges for $user:" >> $OUTPUT_FILE
    mysql -h$HOST -P$PORT -u$USER -p$PASSWORD -e "SHOW GRANTS FOR $user;" >> $OUTPUT_FILE
    echo "" >> $OUTPUT_FILE
done

echo "All user privileges have been written to $OUTPUT_FILE"

Почему предоставление USAGE для обычной функции выдает ошибку "Unexpected input 'IN', the most similar input is TO."? Каков правильный способ предоставления разрешений на функции?​

Обычным функциям нельзя предоставлять разрешения, используя IN ALL DATABASES; они могут быть предоставлены только в пределах текущей базы данных. В то время как глобальные функции предоставляются в масштабе ALL DATABASES.