Не правда все это, что только для IBS, работает.
Наверно вы плохо капаете.
Gobur пишет:
по комментам спецов по ядру - в SECADMINE зашита проверка на то кто запускает, т.е. токо IBS может - так что даже если дать права - не прокатывает. Вроде как доп.защита от таких копателей)
Не правда все это, что только для IBS, работает.
Наверно вы плохо капаете.
Gobur пишет:
по комментам спецов по ядру - в SECADMINE зашита проверка на то кто запускает, т.е. токо IBS может - так что даже если дать права - не прокатывает. Вроде как доп.защита от таких копателей)
может плохо - но когда под юзером запускаем операции SECADMIN вываливается ошибка, под IBS то же самое работает на ура. Придумали пока временный вариант запускать sql-plus в клиент- ксрипте, в котором под IBS все делается - промаргивает быстро, пока всех устраивает. Если раскопаем, переделаем - пока не понятно куда копнуть, будем благодаарны за наводку )
по комментам спецов по ядру - в SECADMINE зашита проверка на то кто запускает, т.е. токо IBS может - так что даже если дать права - не прокатывает. Вроде как доп.защита от таких копателей)
Могу предположить, что там проверка на присутствие в группах ADMIN и PICK.
То есть можно дать права группы "продвинутых" пользователей, но на сам АРМ прав не давать, должно всё получиться.
Информация старая, мои мозги могли что-то перепутать.
Нужны опыты на добровольцах.
Ну или можно из-под пользователя запускать JOB от имени IBS и выполнять его немедленно.
по комментам спецов по ядру - в SECADMINE зашита проверка на то кто запускает, т.е. токо IBS может - так что даже если дать права - не прокатывает. Вроде как доп.защита от таких копателей)
Могу предположить, что там проверка на присутствие в группах ADMIN и PICK.
То есть можно дать права группы "продвинутых" пользователей, но на сам АРМ прав не давать, должно всё получиться.
Информация старая, мои мозги могли что-то перепутать.
Нужны опыты на добровольцах.
Ну или можно из-под пользователя запускать JOB от имени IBS и выполнять его немедленно.
последний вариант больше нравится..Но не совсем понятно как это сделать - нет опыта. Спасибо
Есть ли примеры запуска джоба из операции, который потом останавл. Что будет если несколько пользователей одновременно попытаются его запустить (в нем каждый раз должен исполняться меняющийся скрипт - меняется имя пользователя)?
Ну или можно из-под пользователя запускать JOB от имени IBS и выполнять его немедленно.
последний вариант больше нравится..Но не совсем понятно как это сделать - нет опыта. Спасибо
Есть ли примеры запуска джоба из операции, который потом останавл. Что будет если несколько пользователей одновременно попытаются его запустить (в нем каждый раз должен исполняться меняющийся скрипт - меняется имя пользователя)?
Однако как job запустить от имени другого пользователя Oracle не объясняется.
Должно быть, я вообще поспешил с такого рода идеей, не ознакомившись с функционалом dbms_job.
Однако попробую реабилитироваться:
Предположим, что имеется табличка, состоящая из команд, которые необходимо выполнить из-под пользователя IBS.
Предположим, есть задание, запущенное из-под пользователя IBS, которое 1 раз в несколько секунд смотрит в эту табличку и если что-то находит, то выполняет (из-под себя, то есть из-под IBS), а из таблички удаляет.
таким образом, получается, что некий пользователь user может сделать вставку команды в табличку, после чего в цикле начинать из этой таблички читать, и как только результат чтения станет равным 0, операция пойдёт выполняться дальше.
PS: Только что накопал существование DBMS_IJOB, но ещё не работал с ней.
Чт Апр 04, 2013 10:29  Re: Смена группы доступа программным путем
Полезность: Нет оценки
molokov пишет:
этого будеть достаточно чтобы самому организовать то что нужно.
SecAdmin.Insert_User_To_Group(логин пользователя,'короткое имя группы');
SecAdmin.Delete_User_From_Group(логин пользователя,'короткое имя группы');
узнать какие права есть у пользователя :
SELECT USERNAME R
FROM ibs.subj_equal su, ibs.users u
WHERE su.subj_id <> su.equal_id
AND su.subj_id = su.owner_id
AND su.equal_id = u.USERNAME
AND su.subj_id = 'имя пользователя'
Gobur пишет:
Возможно ли вообще такое? .
А у кого-нибудь получилось давать права через пакет Oracle ??
Подскажите, как можно перенести подразделение от одного пользователя к другому в Администраторе доступа? Команда:
this.[DEPART]:=P_USER.[DEPART];
переносит подразделение в Навигаторе, а в администраторе доступа оно остается прежним.
Возможно поможет...
Из документации:
Цитата:
Синхронизация с прикладными подразделениями.
Т.к. в системе безопасности задается однозначное соответствие между подразделениями безопасности и прикладными подразделениями, необходимо синхронизировать принадлежность пользователя системы безопасности и прикладного пользователя соответствующим подразделениям.
Т.е. при перемещении пользователя между подразделениями безопасности из АРМ uadmin, нужно изменить также прикладное подразделение. Для этого служит настройка SET_USER_DEPART. И наоборот, если прикладная логика изменяет подразделение пользователя, то она должна оповестить об этом систему безопасности. Это делается через вызов SecAdmin.ChangeUserDomain.
Настройка SET_USER_DEPART содержит полностью квалифицированное pl\sql-имя операции для смены подразделения. У этой операции должно быть три параметра:
1. user_id number – идентификатор пользователя (ref [USER]).
2. src_dept_id varchar2 – идентификатор исходного подразделения (ref [DEPART]).
3. dst_dept_id varchar2 – идентификатор подразделения назначения (ref [DEPART]).
Вызов этой операции происходит так:
begin <SET_USER_DEPART>(:USER_ID, null, :DEPART_ID); rtl.lock_clear(true); end;
Т.е. src_dept_id всегда null, т.к.:
1. Его можно определить, зная user_id
2. В общем случае пользовательское подразделение в системе безопасности может не совпадать с реальным подразделением, в котором находится пользователь.
Эта операция не должна звать SecAdmin.ChangeUserDomain, чтобы избежать рекурсии (возможно бесконечной).
Для оповещения системы безопасности о смене подразделения пользователя, в прикладной логике нужно звать следующую процедуру из пакета SecAdmin:
procedure ChangeUserDomain(p_user varchar2, p_domain varchar2, p_exec_date date := null, p_change_dept varchar2 := '1');
В p_exec_date нужно передавать null, чтобы смена подразделения происходила немедленно. В p_change_dept нужно передавать ‘0’, чтобы избежать бесконечной рекурсии (этот параметр определяет, нужно ли вызывать операцию из SET_USER_DEPART). В p_user передавать реквизит [USER].[USERNAME], а в p_domain передавать значение, которое вернет для [USER].[DEPART] следующая функция пакета SecAdmin:
function AppIdToDomain(p_app_id varchar2) return varchar2;
подскажите пожалуйста - можно ли где нибудь в документации посмотреть синтаксис команды Secadmin (интересуют реквизиты и операции)
В поставке ТЯ есть папка Doc, в ней файл access.doc, там и находится описание пакета secadmin
увы, но там нету. Я уже смотрел. Хотелось бы такое сделать:
(цитата из того самого access.doc)
Цитата:
при перемещении пользователя между подразделениями безопасности из АРМ uadmin, нужно изменить также прикладное подразделение. Для этого служит настройка SET_USER_DEPART.
а чтоб это сделать надо сначала прочитать подразделение, которое в Администраторе доступа и записать его в Навигатор (обратная процедура, кстати, делается легко. А вот именно эта сторона вызывает затруднение).
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете голосовать в опросах
Домен cftclub.ru не связан с ЗАО "Центр Финансовых Технологий" и ни в коей мере не нарушает авторских и иных прав
Владелец может не разделять мнения Участников и не несет ответственности за их публикации
Powered by phpBB