Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

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

AlexanderSK © (2004-07-01 14:03:00)
Подскажите, пожалуйста, как в InterBase-е лишить пользователя прав на внесение изменений в метаданные БД?

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

stud (2004-07-06 09:53:00) [1]
по умолчанию права на изменение созданных объектов имеет создатель или администратор БД. обычный пользователь не сможет изменить уже созданные объекты. а на кой черт он будет создавать новые?

AlexanderSK (2004-07-05 17:14:00) [2]
Мжет быть на Firebird 1.5 это делается как-нибудь по другому?
Не так как на IB?

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

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

stud (2004-07-05 16:19:00) [4]
а зачем это нужно, если не секрет???? какой смысл в этих запретах? каким образом пользователь вообще изменяет метаданные?
это уже не пользователь а программист

AlexanderSK (2004-07-05 15:43:00) [5]
Сделал не помогает!
У меня сервер FB1.5.

y-soft (2004-07-05 15:23:00) [6]
>AlexanderSK (05.07.04 14:47) [11]

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

AlexanderSK (2004-07-05 14:47:00) [7]
>y-soft © (05.07.04 13:43) [10]

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

y-soft (2004-07-05 13:43:00) [8]
Кроме GRANT существует и REVOKE

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

AlexanderSK (2004-07-05 11:07:00) [9]
Помогите разобраться!

AlexanderSK (2004-07-01 16:08:00) [10]
Ну не уж то никто никогда этого не делал?

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

}|{yk (2004-07-01 15:15:00) [12]
Причем тут роли? Раздавать роли на системные таблицы, что ли? В Оракле есть триггеры уровня схемы, которыми действительно можно запрещать все что угодно, в FB кажется такого нет (опять же если не раздавать гранты на системные таблицы)

Соловьев (2004-07-01 14:41:00) [13]
http://ibase.ru/devinfo/sqlroles.htm

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

GanibalLector (2004-07-01 14:20:00) [15]
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:06:00) [16]
>GanibalLector © (01.07.04 14:05) [1]
Если можно по подробнее?

GanibalLector (2004-07-01 14:05:00) [17]
назначить роли

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »