Здравствуйте, Слава, Вы писали:

С>И у java и у clr есть security context, который может запретить коду делать вообще всё, кроме вычислений. Далее, хранимка может исполняться под указанным пользователем БД.

Ну и? Я ниже тоже самое и написал. Вы сможете это все настроить, и предвидеть последствия того или иного разрешения?

A>>Это другое, здесь именно риск получения доступа на уровне операционной системы. Я, конечно, понимаю всякие системы прав, песочницы, домены, но настройка сильно усложяется, и можно, не заметив, выдать слишком много прав.

A>>Вот, например, просит приложение выдать ему:
A>>

A>>dbms_java.grant_permission(user_name, 'SYS:java.lang.reflect.ReflectPermission', 'suppressAccessChecks', '');
A>>

A>>И как админу на это реагировать?

С>Знаете, у вас тут есть два малосочетаемых утверждения. Первое — что в конторе глупые или отупевшие от избытка работы админы, а второе — что по соседству с этими админами сидят чрезвычайно хитроумные программисты, которые пролезут через песочницу. Ситуация из каждого из этих утверждений может существовать в реальности, но не в одной конторе точно. Или — или. Это ведь не тред "как с помощью хранимок защититься от промышленного шпионажа".

Вопрос так не стоит. Вопрос следующий: как не открыть дыру с помощью хранимок?

Где я писал, что админы тупые? Наоборот, хороший админ сторонней организации пошлет вас лесом с подобными запросами. У него на сервере несколько баз, а тут вы такой красивый являетесь и говорите -- дай прав. Вы сможете его только административным ресурсом продавить. И зачем все это, если все тоже самое можно получить в приложении? Без всяких головоломок: собрали контейнер, установили, настроили, запустили. От базы только строка подключения нужна.