Архив форумов ЦИТФорума

[=Fluf=]

В m$sql есть функция nest_level(). она выдаёт уровень вложенности кода.

Я хочу решить тривиальную задачу на PostgreSQL.

Есть таблица tb0. на ней висит триггер tr0, который ведёт на триггерную функцию tf0. она добавляет некую строку в другую таблицу tb1 и возвращает NEW.

В целях соблюдения правила целостности данных, я хочу запритить инсерты, апдейты и делеты в таблицу tb1 со всех мест, кроме триггерной функции tf0, или других триггерных функций или процедур.

В m$ можно было бы повелить на эту таблицу tb1 триггер tr1 и триггерную функцию tf1, которая при срабатывании смотрела бы уровень вложенности когда. Так, если встретиться insetr into tb1 в триггерной функции tf0, то при выполнении функции nest_level() в триггерной функции tf1 мы получим 2. (Сам не пробавал, но так в документации написано =) m$ неузаю... ) ) А если бы исерт был напрямую из запроса, в таблицу tb1, то nest_level() в tf1 выдал бы 1.

Мне надо сделать нечто подобное в pgsql. А именно мне надо из кода в tf1 как либо узнать, был ли запущен триггер tr1 внешним запросом или он сработал из-за инсерта/апдейта/делета, совершённого из другой триггерной функции/хранимой процедуры.


====== Сам вопрос ========

Я уверен, что все вы решали эту задачу, но возможно совершенно другим потём. Материализую задание для понимания.

Это банальное написание лога.
Предположим есть таблица main и log. При добавлении в строки в main, автоматически заноситься запись в таблицу log, что такой то юзведь добавил строку в main. Если удалить строку из main - она удалиться, и в log автоматически запишеться, что такой то юзверь удалил строку из main.

Если кто то сделает инсерт в таблицу log о том, что некая строка в main была удалена, а на самом то деле её никто не удалял - получиться нарушение целостности данных.

Как это предотвратить??

[критикан]

есть определённые сомнения в необходимости учёта уровня вложенности для контроля целостности. относительно вопроса о соответствии таблицы и лога: если в логе появятся подряд идущие записи "insert" и "delete", является ли это нарушением целостности? думаю -- нет. поэтому исходный вопрос относится не целостности базы данных, а к достоверности информации в ней, а это решается цифровой подписью, а не уровнем вложенности триггера
----------------
зачем слону два хвоста?

[=Fluf=]

Хм, ну под целостностью данных в БД как раз и подразумевается непротипоречивость данных в разных частях БД (в разных таблицах). О достоверности речи не идёт.
Черь идёт о возможности грубой ошибки работы администратора (последующего суппорта).
Приведу наиболее простой пример.
В моей БД на некоторые таблицы вообще нельзя делать delete. В таблицы содержатся некие диапазоны бланков. А так же логин того, кто сделал запись. Удаление записи делается insert-ом, и вводить надо тот же диапазон, но с отрицательным знаком, атак же логин и пароль. Триггер проверяет логин и пароль, а затем делает delete соответствующего диапазона. Пользователю, а он же нерадивый администратор, делать delete самому нельзя.
Как мне поставить такой запрет?

Слишком долго расказывать все подробности моего приложения. Но суть такова - мне надо, что бы из некой таблицы всякий триггер пог сделать delete или update. А пользователь - нет.

[критикан]

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

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

структура таблицы-инфо: код, количество в штуках
структура таблицы-справочника: код, наименование

ситуация, когда имеет место:

-- целостность+достоверность (всё хорошо):
содержимое таблицы-инфо: 5, 15
содержимое таблицы-справочника: 5, 'стул'

-- нецелостность+достоверность (в справочнике отсутствует запись с кодом 5):
содержимое таблицы-инфо: 5, 15
содержимое таблицы-справочника: 4, 'стул'

-- целостность+недостоверность (воздух в штуках не измеряют, но СУБД об этом не знает, поэтому целостность не нарушена, а для потребителей это бессмыслица, поэтому информация недостоверна):
содержимое таблицы-инфо: 5, 15
содержимое таблицы-справочника: 5, 'воздух'

-- нецелостность+недостоверность (всё плохо):
содержимое таблицы-инфо: 5, 15
содержимое таблицы-справочника: 4, 'воздух'


Что касается вопроса о запрете удаления записей, то эта задача решается разделением функции администрирования на "администратора безопасности" и "администратора содержимого". "Администратору содержимого" (он же нерадивый администратор) ставят запрет на, в частности, прямое управление записями, а дают права на специальные процедуры, предназначенные для администрирования содержимого. Сами процедуры, естественно, должны быть сделаны так, чтобы не допускать нарушений безопасности -- в данном случае они должны вместо удаления выполнять ввод записей с отрицательным знаком.
------------------
Танк запросто вспашет поле, но зачем трактористу танк?

[=Fluf=]

@@@@@
"Администратору содержимого" (он же нерадивый администратор) ставят запрет на, в частности, прямое управление записями, а дают права на специальные процедуры, предназначенные для администрирования содержимого
@@@@@

Так в этом то весь и вопрос - как это сделать??! С другими БД не было вопросов, но как это сделать менно в PostgreSQL??!! Ведь привелегии тут unix-образные, т.е. если пользователь не может делать делете из таблицы, то и запускаемая от его имени хранимаю процедура этот делет сделать тоже не сможет. Вот я сейчас написал таблицу, хранимую процедуру (только взял не делет а инсерт), запрос и вывод (запрос выполнен от пользователя 'math_user'):


######################
############## Таблица:
######################

CREATE TABLE math.qwe
(
q boolean NOT NULL,
CONSTRAINT qwe_pkey PRIMARY KEY (q)
)
WITHOUT OIDS;
ALTER TABLE math.qwe OWNER TO postgres;



#######################
####### Хранимая процедура:
#######################

CREATE OR REPLACE FUNCTION math.f_qwe()
RETURNS boolean AS
$BODY$begin
insert into math.qwe values (true);
return null;
end;
$BODY$
LANGUAGE 'plpgsql' VOLATILE;
ALTER FUNCTION math.f_qwe() OWNER TO postgres;
GRANT EXECUTE ON FUNCTION math.f_qwe() TO math_user;



####################
####### Запрос и вывод:
####################

select math.f_qwe();

ERROR: permission denied for relation qwe
SQL state: 42501
Context: SQL statement "INSERT INTO math.qwe values (true)"
PL/pgSQL function "f_qwe" line 2 at SQL statement

[критикан]

Я с самим постгрессом не баловался, поэтому сразу не скажу, какие команды нужно дать, а общая идея -- запускать эти спецпроцедуры не от имени ограниченного пользователя (он же нерадивый админ), а от имени пользователя с большими правами. Наверняка, эта возможность имеется, и скорее всего она выглядит так: владельцем спецпроцедуры является пользователь с большими правами, а исполнять её может пользователь с маленькими правами. Во всяком случае, если постгресс придерживается политики юниксов в отношении прав, то в нём реализовано право, аналогичное атрибуту SUID, то есть право исполнения от имени владельца команды, а не от имени запускающего.

Итого: нужно поискать в пострессе опции запуска от имени другого пользователя
----------------
Если нет сохи, то почему бы не воспользоваться плугом?

[gray_hemp]