11.02.2008 10:14
Mihon
 
Я о табличках SMGrantedModules и SMGrantedFunctions.
Такой вопрос:
Если у должности есть права на функции, но право на модуль я убираю, чем это чревато для пользователя и для системы?

Думаю, доступ к разделу непосредственно в Супермаге этот пользователь получить не сможет... Но может есть какие-нибудь "подводные камни"?
11.02.2008 12:17
Mihon
 
попробовал добавить доступ для должности "Ревизор" к модулю "эл. весы", не давая доступ к функциям этого модуля. запускаю скрипт, номально, захожу в админ.модуль, вижу что модуль стал доступен. там же (в админ.модуле) пытаюсь убрать права на модуль, получаю:

Цитата:
Ошибка при отзыве у должности прав доступа к модулю.
Ошибка оператора revoke. Подробнее см. в таблице SSEventLog
ORA-20511: Ошибка оператора revoke. Подробнее см. в таблице SSEventLog
ORA-06512: на "SUPERMAG.CORE", line 262
ORA-06512: на "SUPERMAG.ADMINOFFICE", line 73
ORA-01951: ROLE 'SUPERMAG_MODULE_SCALES' не разрешена для 'Ревизор'
ORA-06512: на "SUPERMAG.ADMINOFFICE", line 169
ORA-06512: на line 2
begin
Supermag.AdminOffice.RevokeRole('1',22,10); end;
13.02.2008 10:09
Mihon
 
Как я понял, помимо записи в таблице нужно еще права на роль раздать...
Убрать право на доступ получается, а вот дать-на вид все нормально, но при попытке воспользоваться данным правом выходит ошибка, про role что-то там.
13.02.2008 10:28
Mihon
 
https://olegon.ru/showthread.php?t=3448
Прочитал, вижу что надо права для роли (или на роль) установить, но не хватает опыта в sql или sql plus, чтобы написать запросик самому.
Пож-ста, знатоки, приведите простенький примерчик.
Что-то вроде
Код:
BEGIN
  insert into supermag.SMGrantedFunctions(PosID,FuncID,DaysBefore)
  values(1,1,null);
  COMMIT;
END;

BEGIN
delete from supermag.SMGrantedFunctions
where (posid=1) and (FuncID=1);
COMMIT;
END;
13.02.2008 12:22
akonev
 
grant SUPERMAG_MODULE_SCALES to "ревизор"

revoke SUPERMAG_MODULE_SCALES from "ревизор"
13.02.2008 13:40
Mihon
 
Цитата:
Andrew_Konev grant SUPERMAG_MODULE_SCALES to "ревизор"

revoke SUPERMAG_MODULE_SCALES from "ревизор"
Именно в таком виде?
Как я понял, это даст право только на весы. А как на другие модули?
И "ревизор" - это должно быть "имя пользователя" или "имя пользователя в Oracle"?
13.02.2008 14:10
akonev
 
именно в таком. только еще ; в конце строки.
на другие модули - так же, с указанием другого модуля.
а потом еще то же самое, но с указанием функций вместо модуля.
отдельно для каждой.
я просто написал команды для конкретного случая из твоей ошибки. как образец

идея такая: система безопасности супермага полностью отражается на систему безопасности оракла.

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

Каждой должности супермага тоже соответствует оракловая роль.
Чтобы пользователь получил доступ к нужным объектам из базы, ему даются права должности (т.е. роли).
Этой должности даются права модуля и его функций.
Всей этой механикой занимается "Администратор".

А то, что ты правил в табличках - это всего лишь доступ к интерфейсу соответсвующих модулей СМ2000.
Получается, что вызвать модуль юзер может, а потом уже супермаг к нужным объектам в базе достучаться не может. оракл не пускает. прав нету.

Если тебе не судьба разбираться со всей этой иерархией прав (лично я бы не стал в такой ситуации) - сделай проще:
создай две разные должности для этих своих ревизоров.
тогда будешь действовать так
1) пересаживаешь юзера на другую должность
2) отбираешь (revoke) старую роль должности
3) выдаешь (grant) новую
а все нужные оракловые права уже есть у роли должности.
13.02.2008 14:17
akonev
 
Цитата:
Mihon И "ревизор" - это должно быть "имя пользователя" или "имя пользователя в Oracle"?
я вообще по наивности полагал, что это у тебя имя должности в СМ.
это должно быть имя в оракле.

но в общем случае им лучше бы совпадать (имя в СМ и в оракл). а то ж у тебя совсем крышу сорвет. :)
14.02.2008 12:11
Mihon
 
Спасибо за объяснение!

Смысл какой - много баз, и не очень удобно в случае необходимости менять права к модулям и функциям. Хочется автоматом раздавать.
Так что это не конкретный случай с "ревизором", "ревизор" лишь пример.
Есть мысль - в СМ всем должностям все модули/функции добавить, потом программкой ненужные убрать, получается права для роли останутся, но польз. не сможет пользоваться конкретным модулем, ибо по тамличкам запрещено :) может, прокатит?

Теперь вопросы: модули типа SUPERMAG_MODULE_SCALES имеют привязки к табличкам СМ? Или ручками для каждого модуля/функции?
С проверками обстоит та же ситуация?
14.02.2008 12:36
akonev
 
Цитата:
Mihon Есть мысль - в СМ всем должностям все модули/функции добавить, потом программкой ненужные убрать, получается права для роли останутся, но польз. не сможет пользоваться конкретным модулем, ибо по тамличкам запрещено :) может, прокатит?
должно прокатить.
если тебя не тревожит, что искусственно ослабляешь систему защиты - вперед и с песней.

Цитата:
Mihon Теперь вопросы: модули типа SUPERMAG_MODULE_SCALES имеют привязки к табличкам СМ? Или ручками для каждого модуля/функции?
С проверками обстоит та же ситуация?
у каждого модуля и у каждой функции (у ролей для них, конечно же) свой собственный набор привелегий на доступ к объектам базы.
необходимый и достаточный для работы именно этой функции или, в случае модуля - для работы всего в этом модуле, что не выделено в отдельные функции.
это не привязка к таблицам, это привелегии.
например: этой роли можно писать в такую-то таблицу и читать вот из этих трех, а еще можно запускать такую-то хранимую процедуру.
естественно, привелегии прописаны именно на те объекты, с которыми работает конкретная функция.

проверки, насколько помню, срабатывают на уровне кода СМ.
может быть, на уровне триггеров в базе. не помню.
но, в любом случае, на оракловую безопасность никак не отражаются.
Часовой пояс GMT +3, время: 15:43.

Форум на базе vBulletin®
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.