|
|
|
создание приложения + БД
|
|||
|---|---|---|---|
|
#18+
я так понимаю есть твёрдые рекомменации для корректного создании БД: 1) создать пользователей с соответствующими схемами - владельцев объектов БД (таблиц процедур и т.д) и у них отключить режим подключения к БД (роль CONNECT). Тогда получается, что бы создать дополнительный объект в соотв схеме (не путать с TABLESPACE), необходимо временно дать пользователю право подключения, подключиться создать всё что надо и отключить CONNECT и никак иначе или я где то не прав? 2) роль CONNECT существует для совместимости с предыдущь версиями рекоммендуется вместо роли CONNECT использовать привилегию CREATE SESSION (к стати интересно в чём преймущество)? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2002, 08:41 |
|
||
|
создание приложения + БД
|
|||
|---|---|---|---|
|
#18+
По хорошему пользователи с базой ничего сами не могут делать. Создавать таблички прцедуры и прочее это для программистов и админов. Пользователя надо: -Создать -Дать роль CONNECT После этого он может подключиться к базе по своим логином и максимум, что может: -сделать disconnect (туда ему и дорога) -сделать сonnect -сделать select * from dual На все остальное ему надо дать права, а как он поработал отобрать А что касается CREATE SESSION, то это системная привилегия, а CONNECT это роль, что касается преимуществ, то это для каго как удобно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2002, 10:53 |
|
||
|
создание приложения + БД
|
|||
|---|---|---|---|
|
#18+
Если сам просто так учишься - заведи одного DBA себе и все создавай под ним, а в приложениях лезь в базу под обычным юзером с ролью коннект или привилегией create_session. +c правами на селект и т.д. на соответствующие объекты(таблицы, последовательности, процедуры). Роль - это набор привилегий, они видны в security manager. Ну а потом можно у этого DBA connect отнять, что бы никто к теебе не залез под ним. Конечно вместо DBA - владельца всех объектов можно кого и попроще завести. но потом на приктике все равно придеться ему прав новых добавлять ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2002, 10:58 |
|
||
|
создание приложения + БД
|
|||
|---|---|---|---|
|
#18+
Кому-то захотелось поумничать... темный лес. Роль CONNECT представляет собой: System privileges granted: ALTER CLUSTER - какого черта это нужно рядовому пользователю? CREATE DATABASE LINK - какого черта это нужно рядовому пользователю? CREATE SEQUENCE - какого черта это нужно рядовому пользователю? CREATE SESSION - обязательно нужно! Не подконектится иначе CREATE SYNONYM - какого черта это нужно рядовому пользователю? CREATE TABLE - какого черта это нужно рядовому пользователю? CREATE VIEW - какого черта это нужно рядовому пользователю? Рекомендации по созданию рядовых пользователей звучат примерно так! 1. назначьте пользователю необходимые системные привилегии: - CREATE SESSION - ALTER SESSION - BECOME USER (не совсем ясно для меня зачем это нужно, носудя по названию стоит назначать) 2. для соответствующей схемы с данными создаются роли и им назначается соответсвующий доступ к объектам СУБД 3. каждому пользователю назначаются роли в соответсвии с объектами, которые ему необходимо использовать (скорее приложению с которым он работает И еще. Я на своей практике сталкивался как с перманентно установленными правами, так и назначаемыми в ходе работы, так же можно комбинировать эти методы. Но на мой взгляд второй способ не лучше первого, а скорее хуже, потому как загружает СУБД бесполезной работой по GRANT/REVOKE. Потому что назначая права пользователю мы никак не учитываем сессию. Скажем я запускаю программу, которая запустив нужный джоб назначила мне права на все объекты СУБД. Теперь я лезу в базу простым SQLPLUS и... обладаю в базе теме же правами, которых мне давать просто так не хотели. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2002, 11:16 |
|
||
|
создание приложения + БД
|
|||
|---|---|---|---|
|
#18+
1. Сдаётся мне, что BECOME USER -- из комплекта IMP_FULL_DATABASE. Т.е. простому смертному юзверю противопоказана. 2. Пользователю желательно давать права на вьюшки и процедуры, причём в определение вьюшки должен включаться вызов некоей функции, которая определяет, можно ли данному юзверю в данный момент иметь доступ к этим данным. А самый изящный метод был, когда кроме того, что привелегии выдавались сперва роли, а потом уже роль юзверю, так ещё и роль юзверю давалась с NO DEFAULT. Итого, права юзверю как бы даны, но в неактивном состоянии. А когда юзверь подключается, он вынужден вызвать процедуру из некоего (wrapped ) пакета, которая проверит из какого приложения произошло соединение (и пошлёт, если это не формы), адрес и т.д., а потом сделает SET ROLE ... IDENTIFIED BY <encrypted password> ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2002, 23:42 |
|
||
|
создание приложения + БД
|
|||
|---|---|---|---|
|
#18+
Tochno! Tak i znal. vSkv... no i s moej i s vashej storoni BECOME USER - eto vsego lish predpolozenie... a gde fakti? Nado pokopatsja v dokumentacii. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2002, 13:38 |
|
||
|
создание приложения + БД
|
|||
|---|---|---|---|
|
#18+
Неа. С моей стороны это было почти утверждение -- я специально в три ночи полез за компактом с документацией и проверил сие утверждение (что BECOME USER входит в состав IMP_FULL_DATABASE). Правда там как-то неясно написано, то ли это именно BECOME USER, то ли BECOME ANY USER. В общем, проверить можно только с помощью Security Manager, коий дома, в комплекте с персоналкой, пока весьма необычная вещь. Я до такого ещё не дошёл Мне и так хватает ночных кошмаров на тему DoS из-за того, что VALIDATE STRUCTURE (на семёрке) намертво локает таблицу ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2002, 20:58 |
|
||
|
|
start [/forum/topic.php?fid=52&fpage=2849&tid=1993384]: |
0ms |
get settings: |
10ms |
get forum list: |
12ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
29ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
50ms |
get tp. blocked users: |
2ms |
| others: | 294ms |
| total: | 421ms |
| 0 / 0 |
