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

A>Здесь опять-таки вопрос разграниечения доступа. Под каким системным пользователем работает процесс, в котром иполняется процедура? Наверняка под каким-то пользователем, который имеет расширенные права с возможностью чтения всех data-файлов. В сервере же приложений разные модули могут работать под разными пользователями и даже на разных машинах.

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

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

A>Здесь опять-таки вопрос разграниечения доступа. Под каким системным пользователем работает процесс, в котром иполняется процедура? Наверняка под каким-то пользователем, который имеет расширенные права с возможностью чтения всех data-файлов. В сервере же приложений разные модули могут работать под разными пользователями и даже на разных машинах.

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

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

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

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

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

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