Собственно сабж. Тема касается разграничению прав доступа по мандатным меткам. Столкнулся с такой проблемой, есть 2 таблицы одна главная вторая подчиненная. Запись данных происходит следующем образом: Пользователь вызывает функцию, которая производит запись в подчиненную таблицу, на этой таблице стоит BEFORE INSERT OR CHMAC триггер, который в свою очередь производит запись в главную таблицу. Пользователь, вызывающий функцию находится под грифом секретно(3). Проблема возникает следующая - триггер срабатывает нормально и у добавленной записи устанавливается правильная метка maclabel = {3,0}, а вот в у в подчиненной таблице на запись устанавливается не правильно maclabel = {0,0}. В чем может быть проблема? все доки, хоть и кривые выкурил полностью. Да и еще, если выключить триггер, и сначала сделать INSERT в главную, а потом вызвав функцию записать в подчиненную то все метки устанавливаются верно maclabel = {3,0}. Я конечно понимаю, что можно перенести код триггера в функцию и не замарачиваться, но тут ситуации разные и не всегда получится нормально избежать BEFORE триггер. Заранее спасибо за ответы.

Gold_Slava Soloviev,
Приведите пример. У триггерной функции установлен SECURITY DEFINER?
А зачем SECURITY DEFINER? Интересует как раз текущая метка пользователя, а не создателя функции...
Хотя побывал и так и так.

Тут даже проверил если триггер не отключать, а в подчиненную таблицу сделать запись не через функцию, а простым INSERT, то то-же все верно выходит :) обе метки правильные. Видимо, это все-же баг... не работает исключительно функция+ BEFORE триггер.

Пример:
CREATE TRIGGER tr_tb_vfs_insertorupdate
BEFORE INSERT OR CHMAC
ON duty.tb_vfs
FOR EACH ROW
EXECUTE PROCEDURE objekt.sp_tr_obs_insertorupdate();
----------------------------------------------------------------------------
CREATE OR REPLACE FUNCTION objekt.sp_tr_obs_inserorupdate()
RETURNS trigger AS
$BODY$
DECLARE
BEGIN
IF (TG_OP = 'INSERT') THEN
IF new.tb_obs_id IS NULL THEN
SELECT uuid_generate_v1 INTO new.tb_obs_id FROM "public".uuid_generate_v1();
END IF;

IF EXISTS(SELECT * FROM objekt.tb_obs where tb_obs_id = new.tb_obs_id) THEN
RETURN new;
END IF;

IF TG_RELNAME = 'tb_vfs' THEN
INSERT INTO objekt.tb_obs (tb_obs_id, tk_tob_code) VALUES (new.tb_obs_id, '110100');
END IF;
RETURN new;
END IF;
END;
$BODY$ LANGUAGE plpgsql VOLATILE SECURITY INVOKER
COST 100;
ALTER FUNCTION objekt.sp_tr_obs_insertorupdate() OWNER TO postgres;
GRANT EXECUTE ON FUNCTION objekt.sp_tr_obs_inserorupdate() TO public;
GRANT EXECUTE ON FUNCTION objekt.sp_tr_obs_inserorupdate() TO postgres;
GRANT EXECUTE ON FUNCTION objekt.sp_tr_obs_inserorupdate() TO user_01;
MAC LABEL ON FUNCTION objekt.sp_tr_obs_inserorupdate() IS '{0,0}';

big-trotМогут предложить только кастыльный вариант, явно писать мандатные метки при вставке. А в общем случае это скорее всего баг, мандатная метка не может меняться в сеансе. Есть смысл написать в службу поддержки Русбитеха и выложить им пример.
Да если костыль, то еще проще :) просто избегать создание триггеров, работать исключительно через функцию. Да и новая версия вышла, у меня еще на основе postgresql 9.3, проверю сегодня, может там пофиксели давно...

mefmanРазбивать текст на абзацы вас не учили?
8 строк? самому не смешно. Может по делу что имеете сказать?

Gold_Slava Solovievпропущено...

8 строк? самому не смешно. Может по делу что имеете сказать?

mefman - прав. Тяжеловато читается.

а что будет если выполнить
MAC LABEL ON FUNCTION objekt.sp_tr_obs_inserorupdate() IS '{2,0}';
Это установка привилегии на объект, а не на записи. То есть эта функция не будет видна из под 0 и 1 грифа, а начиная со 2 будет видна.