Не правда все это, что только для 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.
а чтоб это сделать надо сначала прочитать подразделение, которое в Администраторе доступа и записать его в Навигатор (обратная процедура, кстати, делается легко. А вот именно эта сторона вызывает затруднение).
Часовой пояс: GMT + 3 На страницу Пред.1, 2, 3След.
Страница 2 из 3
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете голосовать в опросах
Домен cftclub.ru не связан с ЗАО "Центр Финансовых Технологий" и ни в коей мере не нарушает авторских и иных прав
Владелец может не разделять мнения Участников и не несет ответственности за их публикации
Powered by phpBB
О проекте
Поиск
Отзывы
Регистрация
Вход
