|
|
|
Помогите разобраться с правами на системные таблицы
|
|||
|---|---|---|---|
|
#18+
Требуется предоставить обычному пользователю (не SYSDBA) права на исполнение процедуры, которая напрямую добавляет и удаляет записи таблицы RDB$USER_PRIVILEGES. От SYSDBA процедура исполняется корректно. Самой процедуре права на указанные действия предоставлены. Пользователю - на исполнение процедуры тоже. Судя по сообщению об ошибке при добавлении и удалении записей таблицы RDB$USER_PRIVILEGES срабатывают системные триггеры, которые, видимо, должны производить действия с другими системными таблицами. Тело триггеров в IBExperte не видно, вероятно они хранятся только в компилированном виде. ??? Кто нибудь знает какими еще правами надо снабдить процедуру, либо где посмотреть содержание системных триггеров ??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2002, 10:38 |
|
||
|
Помогите разобраться с правами на системные таблицы
|
|||
|---|---|---|---|
|
#18+
Привет! Наверное, стоит открыть специальный форум "Как гарантированно огрести себе проблем". И первым сообщением там будет пост о необходимости править системные таблицы в InterBase. С уважением, Алексей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2002, 10:58 |
|
||
|
Помогите разобраться с правами на системные таблицы
|
|||
|---|---|---|---|
|
#18+
Спасибо за совет. :-) Но неужели там настолько все страшно сложно устроено, что проблемы будут гарантированы и от таких операций следует отказаться напрочь? Извиняюсь за то, что похоже прошу потдверждения, уже раз прямо сказанного. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2002, 11:10 |
|
||
|
Помогите разобраться с правами на системные таблицы
|
|||
|---|---|---|---|
|
#18+
Привет! Не то чтобы сложно. Просто очень много зависимостей, которые определены не в системных таблицах и их саттелитах (не на уровне SQL, скажем так), а именно в исходном коде сервера. Фактически, системные таблицы - лишь проекция механизмов сервера на SQL. Гарантировать, что эта проекция 100% отображается в обе стороны - нельзя. Более того, есть сатья Чарли Каро по поводу обработки DDL - так вот, там прямо указано, что DDL не равен набору DML для модфикации системных таблиц. Единственный гарантирующий отсутствие глюков и проблем способ общения с системными таблицами - это через DDL. Да, я тоже изредка пользуюсь прямой модифкацией таблиц, но в основном это укладывается в 3 случая - 1) копирование прав пользователя (пример SQL-запроса есть в книге), 2) создание индексов на системные таблицы для ускорения операций с ними, что полезно при очень большом объеме метаданных в БД (пример скрипта есть на ibase.ru), 3) починка битой БД, когда важно вытащить данные, а на саму базу как целостный файл - начихать. Поэтому всем рекомендую не лазать в системные таблицы с целью модфикации С уважением, Алексей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2002, 12:06 |
|
||
|
Помогите разобраться с правами на системные таблицы
|
|||
|---|---|---|---|
|
#18+
Моя задача, как раз вроде бы укладывается в приведенные рамки, мне нужно автоматически копировать права одного пользователя другому. Проблема в том, что требуется это делать: 1. не от SYSDBA, а от простого пользователя 2. не прямым insert-ом, а через хранимую процедуру, чтобы этот простой пользователь ничего другого с RDB$USER_PRIVILEGES не вытворял И вот какие же права надо дать этой хранимой процедуре? И еще, корректно ли удаляются права пользователя по следующему запросу: Код: plaintext 1. Торжественно клянусь по другим поводам системные таблицы прямо не беспокоить. ;-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2002, 15:33 |
|
||
|
Помогите разобраться с правами на системные таблицы
|
|||
|---|---|---|---|
|
#18+
Вот прочитал: http://www.cvalde.com/features/f5/new_error_codes.htm isc_no_write_user_priv (335544742L). In IB4, clients were allowed to write directly to system table RDB$USER_PRIVILEGES that was new in v4 to manage SQL permissions instead of the old RDB$SECURITY_CLASSES table. Now, all operations are expected to happen through DDL commands GRANT and REVOKE. Получается - зря я все это, и писать в USER_PRIVILEGES кроме SYSDBA никто не может. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2002, 16:07 |
|
||
|
Помогите разобраться с правами на системные таблицы
|
|||
|---|---|---|---|
|
#18+
Привет! Код: plaintext Ну и слава богу, в общем-то :) С Новым Годом! Алексей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.12.2002, 12:34 |
|
||
|
Помогите разобраться с правами на системные таблицы
|
|||
|---|---|---|---|
|
#18+
Попробуй с помощью комманд Grant и Reloke. Они позволяют изменят права не только админу. Но внимательно прочитай их описание, там есть свойство по которому пользователь может или нет передавать разрешение. А на прямую составлять запросы к системным таблицам не советую. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2004, 09:33 |
|
||
|
Помогите разобраться с правами на системные таблицы
|
|||
|---|---|---|---|
|
#18+
авторПолучается - зря я все это, и писать в USER_PRIVILEGES кроме SYSDBA никто не может. Н у если тока тебя устроит такой вариант - создаешь отдельного пользователя и передаешь ему права SYSDBA. Грубо говоря кланируешь SYSDBA авторinsert into rdb$user_privileges select '<user_name>', rdb$grantor, rdb$privilege, rdb$grant_option, rdb$relation_name, rdb$field_name, rdb$user_type, rdb$object_type from rdb$user_privileges where rdb$user = 'SYSDBA' ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2004, 16:35 |
|
||
|
|

start [/forum/topic.php?fid=40&msg=32402152&tid=1579232]: |
0ms |
get settings: |
7ms |
get forum list: |
13ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
165ms |
get topic data: |
6ms |
get forum data: |
2ms |
get page messages: |
27ms |
get tp. blocked users: |
1ms |
| others: | 199ms |
| total: | 424ms |

| 0 / 0 |
