← На главную стендаОткрыть протокол ЛР-2

ЛР-2. RBAC: роли, наследование и проверка полномочий

БСУБД · transport_lab · этап 1 — 24.09.2026 · этап 2 — 01.10.2026

Сегодня, 24.09.2026, выполняем только этап 1.
Ваша задача: войти в свой стенд, открыть SQL-консоль, по очереди выполнить шаги 1–7 и занести результаты в протокол.

1. Что открыть

  1. Откройте https://ksoib.ru.
  2. Откройте эту инструкцию.
  3. Откройте протокол ЛР-2 в соседней вкладке.
  4. Подготовьте выданные преподавателем номер стенда sNN, логин sNN_student и пароль.

Пароль в протокол не записывать.

2. Вход в свой стенд

  1. На главной странице ksoib.ru найдите карточку своего стенда sNN и нажмите на неё.
  2. На странице Adminer выберите PostgreSQL.
  3. Введите логин sNN_student и выданный пароль.
  4. Укажите базу данных transport_lab.
  5. Войдите.
  6. После входа откройте пункт «SQL-запрос».
Если вход не выполняется — не подбирайте пароль и не меняйте параметры подключения. Сообщите преподавателю номер своего стенда.

3. Что проверяем

Модель уже настроена: sNN_student → student_reader → CONNECT / USAGE / SELECT.

Роли и права самостоятельно не создаём. GRANT/REVOKE не выполняем.

Этап 1 — 24.09.2026

Шаг 1. Убедитесь, что вошли под своей учётной записью

SQL
SELECT current_user, session_user, current_database();
Ожидается: current_user = sNN_student, session_user = sNN_student, current_database = transport_lab.
В протокол: раздел 1 — все три значения.

Если номер роли не совпадает с вашим стендом — остановитесь и сообщите преподавателю.

Шаг 2. Посмотрите свойства своей роли

SQL
SELECT rolname, rolcanlogin, rolinherit, rolsuper, rolcreatedb, rolcreaterole, rolbypassrls FROM pg_roles WHERE rolname=current_user;
Ожидается: LOGIN и INHERIT — true; SUPERUSER, CREATEDB, CREATEROLE, BYPASSRLS — false.
В протокол: раздел 2 полностью. Краткий вывод: роль может входить в БД и наследовать права, но не является административной.

Шаг 3. Проверьте, откуда берутся ваши права

SQL
SELECT member_role.rolname AS member_role, parent_role.rolname AS granted_role FROM pg_auth_members m JOIN pg_roles parent_role ON parent_role.oid=m.roleid JOIN pg_roles member_role ON member_role.oid=m.member WHERE member_role.rolname=current_user;
Ожидается: sNN_student → student_reader.
В протокол: раздел 3. Напишите, что общие права назначены роли student_reader, а персональная учётная запись наследует их через членство.

Шаг 4. Проверьте права на БД и схему

SQL
SELECT has_database_privilege(current_user, 'transport_lab', 'CONNECT') AS can_connect, has_schema_privilege(current_user, 'transport', 'USAGE') AS can_use_transport, has_schema_privilege(current_user, 'transport', 'CREATE') AS can_create_in_transport;
Ожидается: CONNECT = true, USAGE = true, CREATE = false.
В протокол: раздел 4. Подумайте, почему CONNECT и USAGE ещё не дают права изменять данные.

Шаг 5. Посмотрите реальные права на таблицы

SQL
SELECT table_name, has_table_privilege(current_user, format('transport.%I', table_name), 'SELECT') AS can_select, has_table_privilege(current_user, format('transport.%I', table_name), 'INSERT') AS can_insert, has_table_privilege(current_user, format('transport.%I', table_name), 'UPDATE') AS can_update, has_table_privilege(current_user, format('transport.%I', table_name), 'DELETE') AS can_delete FROM information_schema.tables WHERE table_schema='transport' AND table_type='BASE TABLE' ORDER BY table_name;
Ожидается для 12 предметных таблиц: SELECT = true; INSERT/UPDATE/DELETE = false.
В протокол: раздел 5 только для пяти таблиц: passengers, bookings, payments, maintenance_records, operational_events. Весь вывод переписывать не надо.

Шаг 6. Выполните разрешённую операцию

SQL
SELECT booking_ref, fare_amount, currency, status FROM transport.bookings ORDER BY id LIMIT 5;
Ожидается: запрос выполняется успешно и возвращает 5 строк.
В протокол: раздел 6 — «SELECT выполнен успешно» и 1–2 строки результата либо скриншот по указанию преподавателя.

Шаг 7. Завершите этап 1

До окончания пары проверьте, что заполнены разделы протокола 1–6. Затем сформулируйте:

  1. какая роль является вашей персональной;
  2. какая роль является групповой;
  3. какие права наследуются через student_reader;
  4. каких административных прав нет;
  5. как это связано с принципом минимально необходимых полномочий.
На этом этап 1 от 24.09 завершён.

Этап 2 — 01.10.2026

Сегодня этот раздел не выполняем. Он оставлен здесь, чтобы была видна логика продолжения ЛР-2. На следующей части ошибки permission denied будут ожидаемым результатом.

Шаг 8. Запрет UPDATE

SQL
UPDATE transport.bookings SET status=status WHERE false;

Шаг 9. Запрет CREATE TABLE

SQL
CREATE TABLE transport.lab02_probe(id integer);

Шаг 10. Запрет SET ROLE

SQL
SET ROLE operator;

Шаг 11. Служебная таблица

SQL
SELECT has_table_privilege(current_user, 'transport.lab_meta', 'SELECT') AS can_read_lab_meta;

Что сдавать по завершении всей ЛР-2

  1. ФИО и номер стенда.
  2. Идентичность сессии.
  3. Свойства персональной роли.
  4. Членство в student_reader.
  5. Права на БД и схему.
  6. Матрицу прав минимум для пяти таблиц.
  7. Результат разрешённого SELECT.
  8. После этапа 2 — отрицательные проверки.
  9. Вывод 5–8 предложений.
Безопасность: пароль в протокол не включать; чужие учётные данные не проверять; ограничения ролей не обходить; команды вне задания не выполнять.