IB лишение пользователя прав на добавление в БД объетов

← →
AlexanderSK (2004-07-01 14:03) [0]

Подскажите, пожалуйста, как в InterBase-е лишить пользователя прав на внесение изменений в метаданные БД?

Заранее спасибо!

← →
GanibalLector © (2004-07-01 14:05) [1]

назначить роли

← →
AlexanderSK (2004-07-01 14:06) [2]

>GanibalLector © (01.07.04 14:05) [1]
Если можно по подробнее?

← →
GanibalLector © (2004-07-01 14:20) [3]

2 AlexanderSK
Скажу чесно,я в своих проетах такого не использую.
>Если можно по подробнее?
Дык...в книгах пишут.Да и статей полно.Вот,пример:

Рассмотрим пример. Предположим, что у гипотетической системы бухгалтерского учета есть 3 группы пользователей - ролей: "главбух", "кассир" и "расчетчик зарплаты". Должностные обязанности сотрудников определяют следующий доступ к БД программы: все пользователи должны читать данные справочника "План_Счетов"; "расчетчик зарплаты" работает с таблицей "Расчеты_По_Зарплате"; "кассир" работает с таблицей "Операции_По_Кассе"; редактировать справочник "План_Счетов" может только "главбух"; "главбух" ведет операции по учету основных средств - таблица "Операции_ОС"; "главбух" должен контролировать работу подчиненных - значит иметь как минимум доступ на чтение к их данным; "кассир" и "расчетчик зарплаты" не видят операции по основным средствам, а также работу друг друга. Очевидно, что при стандартном подходе использования ролей необходимо сформировать следующие скрипты назначения привилегий: /*1. Роль "Расчетчик":*/ grant select on "План_Счетов" to "Расчетчик"; grant select, insert, update, delete on "Расчеты_ По_Зарплате" to "Расчетчик"; /*2. Роль "Кассир":*/ grant select on "План_Счетов" to "Кассир"; grant select, insert, update, delete on "Операции_По_Кассе" to "Кассир"; /*3. Роль "Главбух":*/ grant select, insert, update, delete on "Операции_По_ОС" to "Главбух"; grant select, insert, update, delete on "План_Счетов" to "Главбух"; grant select on "Расчеты_По_Зарплате" to "Главбух"; grant select on "Операции_По_Кассе" to "Главбух". Пример очень простой, но отражает суть: для каждой роли мы прописываем доступ на чтение справочника "План_Счетов". А поскольку, как говаривал один из моих преподавателей, "жизнь шире наших схем", в реальной системе наберется далеко не одна общая привилегия, которую нужно давать доброму десятку ролей. ...

← →
AlexanderSK (2004-07-01 14:26) [4]

>GanibalLector © (01.07.04 14:20) [3]
Это пример разрешающий доступ добавление и изменение данных.
Я спрашивал про метаданные. Как запретить пользователю добавить в БД например таблицу?!

← →
Соловьев © (2004-07-01 14:41) [5]

http://ibase.ru/devinfo/sqlroles.htm

← →
}|{yk © (2004-07-01 15:15) [6]

Причем тут роли? Раздавать роли на системные таблицы, что ли? В Оракле есть триггеры уровня схемы, которыми действительно можно запрещать все что угодно, в FB кажется такого нет (опять же если не раздавать гранты на системные таблицы)

← →
AlexanderSK (2004-07-01 15:38) [7]

>}|{yk © (01.07.04 15:15) [6]
Вот и я о том же!
Только проблема в том что если запретить доступ к системным таблицам то ни один пользователей кроме SYSDBA не может даже соединиться с БД, а если выдать праова SELECT на все системные таблицы пользователю Public, тогда становиться возможным добавление новых таблиц в БД!
В чем тут дело и как с этим бороться? Подскажите, пожалуйста!

← →
AlexanderSK (2004-07-01 16:08) [8]

Ну не уж то никто никогда этого не делал?

← →
AlexanderSK (2004-07-05 11:07) [9]

Помогите разобраться!

← →
y-soft © (2004-07-05 13:43) [10]

Кроме GRANT существует и REVOKE

Кроме того - зачем трогать все системные таблицы? Есть конкретные таблицы, где и храняться определения полей...

← →
AlexanderSK (2004-07-05 14:47) [11]

>y-soft © (05.07.04 13:43) [10]

А как запретить добавлять новый таблицы?

← →
y-soft © (2004-07-05 15:23) [12]

>AlexanderSK (05.07.04 14:47) [11]

Попробуйте запретить права на изменение и удаление для RDB$RELATIONS или даже RDB$DATABASE

← →
AlexanderSK (2004-07-05 15:43) [13]

Сделал не помогает!
У меня сервер FB1.5.

а зачем это нужно, если не секрет???? какой смысл в этих запретах? каким образом пользователь вообще изменяет метаданные?
это уже не пользователь а программист

← →
AlexanderSK (2004-07-05 16:25) [15]

>stud © (05.07.04 16:19) [14]
>а зачем это нужно, если не секрет????
Для повышения безопасности! Потому-что если этого не сделать любой человек знающий пользовательский пароль может изменить мета данные.

>это уже не пользователь а программист
Необязательно бять программистом чтобы написать простенький SQL-запрос.

← →
AlexanderSK (2004-07-05 17:14) [16]

Мжет быть на Firebird 1.5 это делается как-нибудь по другому?
Не так как на IB?

по умолчанию права на изменение созданных объектов имеет создатель или администратор БД. обычный пользователь не сможет изменить уже созданные объекты. а на кой черт он будет создавать новые?

IB лишение пользователя прав на добавление в БД объетов Найти похожие ветки