Вследствие переписывания запросов Digital Q.DataBase механизмом переписывания запросов, осуществляется доступ к таблицам и представлениям, отличным от тех, что были указаны в исходном запросе. При использовании правил обновления это может включать доступ на запись в таблицы.

У правил переписывания нет отдельного владельца. Владелец отношения (таблицы или представления) автоматически становится владельцем определенных для него правил переписывания. Digital Q.DataBase система правил изменяет поведение стандартной системы управления доступом. За исключением SELECT правил, связанных с представлениями, которые вызываются с правами владельца (см. CREATE VIEW), проверка всех отношений, задействованных вследствие применения правил, выполняется на соответствие привилегиям владельца правила, а не пользователя, инициировавшего правило. Это означает, что, за исключением представлений с правами вызывающего, пользователям необходимы права только на те таблицы или представления, которые явно указаны в их запросах.

Пример: у пользователя есть список телефонных номеров, часть из которых является конфиденциальной, а остальные необходимы для работы помощника офиса. Пользователь может создать следующие объекты:

CREATE TABLE phone_data (person text, phone text, private boolean);
CREATE VIEW phone_number AS
    SELECT person, CASE WHEN NOT private THEN phone END AS phone
    FROM phone_data;
GRANT SELECT ON phone_number TO assistant;

Никто, кроме самого пользователя (и суперпользователей базы данных), не может получить доступ к phone_data таблицы. Однако вследствие действия GRANT, помощник может выполнить SELECT в отношении phone_number представления. Система правил перепишет SELECT из phone_number в SELECT из phone_data. Поскольку пользователь является владельцем phone_number и, следовательно, владельцем правила, проверка прав доступа на чтение к phone_data теперь выполняется на основе привилегий пользователя, и запрос разрешается. Проверка доступа к phone_number также выполняется, но она осуществляется в отношении вызывающего пользователя, поэтому никто, кроме самого пользователя и помощника, не может использовать его.

Проверка привилегий выполняется для каждого правила в отдельности. Таким образом, на данный момент только помощник может видеть общедоступные номера телефонов. Однако помощник может создать другое представление и предоставить к нему общий доступ. Тогда любой пользователь сможет видеть phone_number данные через представление помощника. При этом помощник не может создать представление, которое напрямую обращается к phone_data. (На самом деле помощник может это сделать, но это не сработает, так как при каждой проверке прав в доступе будет отказано.) И как только пользователь заметит, что помощник открыл своё phone_number представление, он сможет отозвать права доступа помощника. После этого любая попытка доступа к представлению помощника завершится ошибкой.

Можно было бы предположить, что такая последовательная проверка правил является уязвимостью в системе безопасности, но на самом деле это не так. Но если бы система не работала таким образом, помощник мог бы создать таблицу с теми же столбцами, что и в phone_number и копировать туда данные раз в день. В таком случае это были бы собственные данные помощника, и он мог бы предоставлять доступ к ним всем, кому пожелает. Команда GRANT означает: ««Я тебе доверяю»». Если кто-то, кому вы доверяете, совершает подобное, стоит пересмотреть ситуацию и использовать команду REVOKE.

Обратите внимание: хотя представления можно использовать для скрытия содержимого определённых столбцов с помощью вышеописанного метода, они не обеспечивают надёжного сокрытия данных в невидимых строках, если только параметр security_barrier флаг установлен. Например, следующее представление является небезопасным:

CREATE VIEW phone_number AS
    SELECT person, phone FROM phone_data WHERE phone NOT LIKE '412%';

Это представление может показаться безопасным, так как система правил будет перезаписывать любую SELECT из phone_number в SELECT из phone_data команду и добавлять условие, согласно которому требуются только те записи, в которых phone не начинается на 412. Но если пользователь может создавать собственные функции, ему будет несложно убедить планировщик выполнить пользовательскую функцию перед выражением NOT LIKE . Например:

CREATE FUNCTION tricky(text, text) RETURNS bool AS $$
BEGIN
    RAISE NOTICE '% => %', $1, $2;
    RETURN true;
END;
$$ LANGUAGE plpgsql COST 0. 0000000000000000000001;

SELECT * FROM phone_number WHERE tricky(person, phone);

Каждое имя и номер телефона из phone_data таблицы будут выведены в виде сообщения NOTICE, так как планировщик предпочтёт выполнить недорогую функцию неочевидный функция перед более затратной NOT LIKE. Даже если пользователю запрещено определять новые функции, встроенные функции могут использоваться в подобных атаках. (Например, большинство функций приведения типов включают входные значения в генерируемые ими сообщения об ошибках.)

Аналогичные соображения применимы к правилам обновления. В примерах из предыдущего раздела владелец таблиц в учебной базе данных мог предоставить права SELECT, INSERT, UPDATE, и DELETE на этом shoelace представление другому пользователю, но только SELECT на shoelace_log. Действие правила по внесению записей в журнал по-прежнему будет успешно выполнено, и другой пользователь сможет их просматривать. Однако он не сможет ни создавать фиктивные записи, ни изменять или удалять существующие. В данном случае невозможно обойти систему правил, заставив планировщик изменить порядок операций, так как единственное правило, которое ссылается на shoelace_log является безусловным INSERT. В более сложных сценариях это утверждение может быть неверным.

Когда представление должно обеспечивать безопасность на уровне строк, к нему следует применить security_barrier данный атрибут должен быть применен к представлению. Это предотвращает передачу значений из строк в потенциально вредоносные функции и операторы до того, как само представление выполнит фильтрацию. Например, если бы приведенное выше представление было создано следующим образом, оно было бы безопасным:

CREATE VIEW phone_number WITH (security_barrier) AS
    SELECT person, phone FROM phone_data WHERE phone NOT LIKE '412%';

Представления, созданные с использованием security_barrier могут работать значительно медленнее, чем представления, созданные без этого параметра. В общем случае этого невозможно избежать: самый быстрый из возможных планов должен быть отклонен, если он может нарушить требования безопасности. По этой причине данный параметр по умолчанию не задействован.

Планировщик запросов имеет больше свободы действий при работе с функциями, не имеющими побочных эффектов. Такие функции называются LEAKPROOF, и включают в себя множество простых, часто используемых операторов, например, многие операторы сравнения на равенство. Планировщик запросов может безопасно разрешить вычисление таких функций в любой момент процесса выполнения запроса, так как их вызов для строк, невидимых пользователю, не приведет к утечке какой-либо информации о скрытых строках. Кроме того, функции, которые не принимают аргументов или которым не передаются аргументы из представления с барьером безопасности, не обязательно помечать как LEAKPROOF быть спущены вниз, так как они никогда не получают данные из представления. Напротив, функция, которая может выдать ошибку в зависимости от значений, полученных в качестве аргументов (например, при переполнении или делении на ноль), не является герметичной (leak-proof) и может раскрыть значимую информацию о скрытых строках, если будет применена до фильтров строк представления с барьером безопасности.

Важно понимать, что даже представление, созданное с параметром security_barrier параметр предназначен для обеспечения безопасности только в том ограниченном смысле, что содержимое невидимых кортежей не будет передаваться потенциально небезопасным функциям. У пользователя вполне могут быть другие способы получения косвенных сведений о скрытых данных; например, он может просмотреть план запроса с помощью команды EXPLAIN, или измерить время выполнения запросов к представлению. Злоумышленник может получить возможность сделать определённые выводы об объёме невидимых данных или даже получить некоторую информацию о распределении данных или наиболее часто встречающихся значениях (поскольку эти факторы могут влиять на время выполнения плана или даже на выбор самого плана, так как они также отражаются в статистике оптимизатора). Если подобные типы атак через «скрытые каналы» вызывают опасения, вероятно, будет неразумно предоставлять какой-либо доступ к данным вообще.