ArcSDE - привилегии

0 голосов
спросил 25 Апр, 03 от KAA (2,020 баллов) в категории Программные продукты Esri
Вопрос вдогонку.
Почему на системные таблицы ArcSDE типа
GDB_FEATURECLASSES и т.д. (GDB_*) при установке дается
GRANT DELETE ON GDB_FEATURECLASSES TO PUBLIC WITH GRANT
OPTION;
GRANT INSERT ON GDB_FEATURECLASSES TO PUBLIC WITH GRANT
OPTION;
GRANT SELECT ON GDB_FEATURECLASSES TO PUBLIC WITH GRANT
OPTION;
GRANT UPDATE ON GDB_FEATURECLASSES TO PUBLIC WITH GRANT
OPTION;

Причем с GRANT OPTIONS !
В чем прикол ? Любой юзер базы данных спокойно может завалить ArcSDE как я понимаю. Можно ли эти гранты убрать, и какие минимальные гранты нужно давать пользователю, чтобы он:
1) Мог только читать таблицы - причем все (включая системные)
2) Мог редактировать таблицы (исключая системные)

11 Ответы

0 голосов
ответил 30 Апр, 03 от Гость (210,080 баллов)
Есть хорошая книга - называется config_tuning_guide_oracle.pdf Поставляется вместе с ArcSDE. Там во второй главе расписаны какие права должны быть у пользователя SDE, у владельца набора данных и других пользователей.
Какие можно убрать, а какие лучше оставить.
0 голосов
ответил 04 Май, 03 от Erkesh (1,080 баллов)
Давно ждал ответа на вопрос, поставленный "КАА" от Специалистов, однако его пока нет. Во-первых, хотелось бы сказать спасибо за то, что заметили, что группе "паблик" разработчиками даются так много привилегий на те объекты, которые сами же разработчики сравнивают с объектами в схеме system (вопрос по-пути - к "КАА" - как заметили? вернее, в каких-то скриптах построения - в каких скриптах? или уже потом, после построения схемы sde?). Думаю, что это неспроста, потому что работая с продуктами от "есри" заметил - ничего просто так разработчики не делают, все в достаточной мере выверено и обдумано. К сожалению, ответа на вопрос - почему группе "паблик" дано так много привилегий на объекты схемы sde и "можно ли их убрать" Григорий Кувшинников не дает. Обратимся к предлагаемому на рассмотрение руководству. Итак - всего в данном руководстве упоминаний "public" - 12 (из них - в заголовке 1, в тексте - 4, в синтаксисе команд - 2 и не относящихся к данному вопросу - (public database link, public synonym и т.д.) - 5). Ни в одном из семи упоминаний предоставления привилегий группе public не говорится про update, delete, insert на таблицы схемы sde. Считаю, что на первую часть вопроса (зачем del., upd., ins. on gdb* даны public) в данном руководстве нет. Кстати - по пути - несмотря на все эти разъяснения - ArcSDE uses the stored procedures of the DBMS_PIPE and DBMS_LOCK Oracle built-in packages. ArcSDE calls stored procedures of the DBMS_PIPE package when it stores and transmits ArcSDE rowids. ArcSDE calls the stored procedures of the DBMS_LOCK package to add a row to the PROCESS_INFORMATION table whenever an ArcSDE session connects. Your Oracle DBA must connect to the Oracle instance as the SYS user and grant execute on these packages to PUBLIC: connect sys/ grant execute on dbms_pipe to public; grant execute on dbms_lock to public; я так и не понял, зачем давать привилегии на выполнение этих пакетов всем? Может, логичнее было бы давать эти привилегии какому-то конкретному пользователю (пользователям), н-р sde? Теперь посмотрим в данном руководстве, какие привилегии нужно отнимать. Проведя поиск по "revok" обнаруживаю, что все отнимания привилегий касаются отнятия привилегий у пользователей, после того, как они один раз подконектились к sde и создали лог-таблицы, либо отнятия привилегий у самого пользователя sde после того, как он обновил таблицы предыдущей версии и т.п., но - ни слова о том, чтобы убрать привилегии на системные таблицы sde. Поэтому считаю, что ответа на вторую часть вопроса (можно ли эти привилегии убрать) данное руководство тоже не дает. Кстати - по пути - в данном руководстве упоминается процедура create_user_and_logfiles из пакета user_util, предоставляемого разработчиками. У меня процедура не срабатывала на вызове процедуры из пакета dbms_stats ни под sys-ом, ни под system-ом - пришлось просто заремить вызовы dbms_stats. Итак, считаю, что ответа все еще нет. Экспериментировать с sde, просто убрав привилегии на системные таблицы из группы "паблик" не хочу, потому что по опыту знаю - эксперименты даже с документированными возможностями sde приводят к плачевным результатам (здесь по пути - пробовал воспользоваться любезно предоставляемой разработчиками возможностью использовать blob вместо long raw - создание данных - отлично - пробовал переименовать класс объектов - "убил" словарь базы данных - ни у кого проблем при использовании blob с sde не возникало? хотя - тут, возможно моя вина). В заключении хочу еще раз подчеркнуть - жду ответа на данный вопрос, потому что вопрос серьезный. Достаточно посмотреть на данный листинг - SQL> select table_name, grantable from dba_tab_privs 2 where owner = 'SDE' and grantee = 'PUBLIC' and privilege in ('INSERT', 'UPDATE', 'DELETE'); TABLE_NAME GRA ------------------------------ --- GDB_ANNOSYMBOLS YES GDB_ANNOSYMBOLS YES GDB_ANNOSYMBOLS YES GDB_ATTRRULES YES GDB_ATTRRULES YES GDB_ATTRRULES YES GDB_CODEDDOMAINS YES GDB_CODEDDOMAINS YES GDB_CODEDDOMAINS YES GDB_DEFAULTVALUES YES GDB_DEFAULTVALUES YES GDB_DEFAULTVALUES YES GDB_DOMAINS YES GDB_DOMAINS YES GDB_DOMAINS YES GDB_EDGECONNRULES YES GDB_EDGECONNRULES YES GDB_EDGECONNRULES YES GDB_EXTENSIONS YES GDB_EXTENSIONS YES GDB_EXTENSIONS YES GDB_FEATURECLASSES YES GDB_FEATURECLASSES YES GDB_FEATURECLASSES YES GDB_FEATUREDATASET YES GDB_FEATUREDATASET YES GDB_FEATUREDATASET YES GDB_FIELDINFO YES GDB_FIELDINFO YES GDB_FIELDINFO YES GDB_GEOMNETWORKS YES GDB_GEOMNETWORKS YES GDB_GEOMNETWORKS YES GDB_JNCONNRULES YES GDB_JNCONNRULES YES GDB_JNCONNRULES YES GDB_NETCLASSES YES GDB_NETCLASSES YES GDB_NETCLASSES YES GDB_NETWEIGHTASOCS YES GDB_NETWEIGHTASOCS YES GDB_NETWEIGHTASOCS YES GDB_NETWEIGHTS YES GDB_NETWEIGHTS YES GDB_NETWEIGHTS YES GDB_NETWORKS YES GDB_NETWORKS YES GDB_NETWORKS YES GDB_OBJECTCLASSES YES GDB_OBJECTCLASSES YES
0 голосов
ответил 05 Май, 03 от Гость (210,080 баллов)
Господа, настройки привилегий к таблицам SDE по умолчанию предназначены для начального старта.
То же самое можно сказать и про сам Oracle. У него тоже много стандартных системных пользователей и паролей. И если администратор не изменит начальных установок, то можно запросто завалить Oracle :). Если Вам не нравится, что все ваши пользователи видят эти таблицы - создайте группу и выдайте ей права. Все пользователи, которые должны читать данные из SDE - должны читать и системные таблицы SDE. Если они просто редактируют данные, то им тоже достаточно просто читать системные таблицы. Если пользователь администрирует данные (создаёт или меняет структуру БГД)- то он должен иметь возможность изменять содержимое этих таблиц.
А чтобы не бояться экспериментов - рекомендую просто создать тестовую конфигурацию. И пока Вы сами не попробуете и не пощупаете никто Вам не поможет. SDE работает на разных операционках и под разными СУБД. И в каждой конфигурации есть свои тонкости. Всех не опишешь заранее.
Успехов.
0 голосов
ответил 05 Май, 03 от Erkesh (1,080 баллов)
Григорий, простите меня, конечно, за мммм, как бы это помягче...
В общем - вот это - "...И в каждой конфигурации есть свои тонкости. Всех не опишешь заранее..." - это детский лепет. Это не про программный документированный продукт.
Еще раз извините.

Что касается Oracle, то и 'manager', и 'change_on_install' и пароль oem sysman-а (не помню навскидку) - документально описаны и рекомендованы к изменению. Кроме знания этих паролей и паролей администраторов сервера, где установлена "оракловая" база - не знаю причин, как можно "завалить" базу в стандартной конфигурации.

Для остальных еще раз оговорюсь - собственный опыт - "щупать" sde "ручками" - довольно опасное для данных занятие, даже если при этом "никто вам не поможет". Да и глупо это - вслепую тыкаться.
0 голосов
ответил 05 Май, 03 от igorstr (6,660 баллов)
Абсолютно согласен с Григорием, в руководстве даны настройки для того, чтобы "работало", а чтобы обеспечить высокий уровень секретности с защитой от собственных пользователей - читайте книги по Oracle, SDE ПОЛНОСТЬЮ, только тогда ПОЛНАЯ картинка вырисуется. Я проблемами секретности не занимался - задачи не было. Могу сказать что естественно, права завышены, на то и админу мозги даны, чтобы их грамотно обрезать. Правильно, всему паблику права на sde'шные таблицы не нужны (да еще и с грантованием). Так дайте права на селект тем юзерам, которые смотрят, и на измение тем, которые изменяют. По статистике - большая часть взломов совершается изнутри, но это забота сисадминов, которые вытаскивают все дисководы (кроме хардов) из системников и отделов кадров, которые не принимают на работу людей с хакерскими наклонностями. Известно, что люди "щарящие" делятся на "админов", которые делают, чтоб "стояло" и "хакеров", которые делают, чтобы "висело". Последних и надо отсекать при приеме на работу посредством спец. тестов (если времени на длительное знакомство нет). Натура все равно велезет... Тесты мне не известны, этим занимаются спец. люди и конторы и берут за это некоторые деньги. Но и пользу от таких получать можно и нужно, например, попросить такого (таких) протестить сетку на предмет дыр. Поверьте, много полезного узнаете. А с документированными возможностями все в порядке, с изменениями формы хранения данных экспериментировал. Оно прописывается в dbtune и указывается с помощью ключевых слов при загрузке данных. Как понял из фразы "пробовал переименовать класс объектов" - было сделано не так. Вот и получилось :<<. Типа "на любой вопрос любой ответ" или "фирма гарантирует полную тайну полета пули". Еще раз - "читайте Маркса", хоть "кирпич" по SDE и достаточно толстый, но его стоит именно читать, а не сканировать. Сканировать имеет смысл, когда что-то забыл. А когда еще и не знал, а потом забыл... Я с очень большим уважением отношусь к Еркешу. Пожалуй, первый человек в СНГ начал глубоко копать права доступа, но все равно - эта конфа доку не заменит.
0 голосов
ответил 05 Май, 03 от igorstr (6,660 баллов)
Ребята, давайте жить дружно.
Что сделать-то хочется - закрыть базу для всех кроме х, у, z - так что мешает?
В каждой конфигурации есть свои тонкости. И это не детский лепет.
Система сделана так, чтобы работать практически в любой конфигурации. Это забота производителя о "конченных" пользователях, которые не знают, с чего начинается sql предложение (поверьте, таких "админов" много). То есть любой создаваемый юзер должен нормально соединяться и делать со своими данными все, что ему заблагорассудется.
А "щупать" надо, естетственно, не на живых данных а на тестовой инсталяции, благо, для тестовых целей можно наплодить столько сервисов, сколько захочется.
Что означает "вслепую" не понимаю. Почти все глюки, которые вам встречались, были прописаны в документации. Возможно, там и нет детального описания прав, но тут должны действовать только разумные ограничения на основе знания структуры хранения данных. Вполне возможно, что если бы ESRI сделал одного тестового юзера с правами только на чтение данных, другого - на чтение и запись, а остальных предложил "делать как в примере", это тоже не всем подошло бы.
Документации много, большая часть ее лежит на сайте ESRI.
0 голосов
ответил 07 Май, 03 от Erkesh (1,080 баллов)
Должен полностью согласиться.
Добавлю только свои извинения за некоторую резкость и пару ссылок для еще сомневающихся в правоте этих слов:
http://forums.esri.com/Thread.asp?c=2&f=59&t=88608#243760 - это правда, о sql-server, но суть примерно та же, что и здесь - http://support.esri.com/index.cfm?fa=knowledgebase.techarticles.articleShow&d=21014 (это уже про oracle, и ссылок, связанных именно с вопросом предоставления "change" on gdb to public штук восемь вывалилось).
Спасибо за разрешение неясного вопроса.
0 голосов
ответил 12 Май, 03 от KAA (2,020 баллов)
Смысл ответов понятен конечно :-)) Я прошу извинить группу техподдержки СДЕ, но не нужно уж так прям защищать СДЕ. Да согласитесь уж - сделан кривовато - недостаточно задокументирован :-)))) Я не понимаю - почему для старта дается грант на весь паблик. Про Оракл нельзя сказать такое - у него стандартные пароли и т.п. - напротив при создании юзера - ему даются минимальные права и их при желании нужно добавлять. Здесь же наоборот - изначально даются максимальные права и их нужно обрезать. С чем я в корне не согласен.
0 голосов
ответил 16 Май, 03 от Гость (210,080 баллов)

С чем не согласны - с тем, что нужно обрезать или с тем, что максимальные? image

Я шучу. Конечно, Вы правы, сделано криво. Но вообще, суть вопроса выяснена - если есть админ (кстати, а Вы помните, что сейчас Oracle активно декларирует - "Oracle без администратора" :)) - то МОЖНО обрезать. )

Я, кстати, и привилегии на execute dbms_pipe and dbms_lock отниму у группы public, скорее всего.

0 голосов
ответил 16 Май, 03 от Alexander1 (32,520 баллов)

Дык радоватьсы надо, что SDE настроек требует!
Иначе, скоко народу куска хлеба лишилось бы!

Или вам хочется ЛЁГКОГО куска? image

Добро пожаловать на сайт Вопросов и Ответов, где вы можете задавать вопросы по GIS тематике и получать ответы от других членов сообщества.
...