Позвольте мне сделать небольшое предположение здесь. Проблема в том, что имена объектов чувствительны к регистру. Быстрое решение заключается в том, чтобы заключить имена объектов в двойные кавычки, например:
GRANT EXECUTE ON SYS."/1005bd30_LnkdConstant" TO mynewpublicrole;
Вы указываете, что «не можете предоставить [EXECUTE ON] SYS./1005bd30_LnkdConstant» роли.
Я предполагаю, что когда вы запустили оператор GRANT, Oracle выдал исключение, скорее всего,
ORA-00903: invalid table name
Заключение имени объекта в двойные кавычки (как показано в примере) должно решить эту проблему.
Невозможно ответить на вопрос, нужна ли вашей новой роли привилегия EXECUTE для этих объектов или нет. Ну, роль не обязательно нуждается в них. Вопрос в том, нужны ли они пользователю (предоставлены напрямую или косвенно через роли.) Это можно определить путем тщательного тестирования.
Некоторые другие комментарии.
Если вы намереваетесь создать новую роль и предоставить эту роль всем пользователям, я не вижу, чтобы безопасность изменилась или улучшилась. Итак, я собираюсь предположить, что это не так.
Похоже, вы пытаетесь применить принцип "наименьших привилегий". Я приветствую это усилие.
Один из наиболее распространенных шаблонов, который я вижу у разработчиков приложений, - это подключение приложения к базе данных в качестве владельца объектов схемы. Это означает, что у приложения есть все виды привилегий, которые ему, вероятно, не нужны, например, УДАЛИТЬ СТОЛ, ИЗМЕНИТЬ ПРОЦЕДУРУ и т. Д.
Шаблон, который мы используем, состоит в том, чтобы иметь пользователя "OWNER", который владеет объектами схемы, и отдельного пользователя "APP", который имеет определенные привилегии, необходимые для объектов "OWNER", и синонимы для объектов "OWNER". (Синонимы позволяют ссылаться на OWNER.object, не будучи квалифицированным с OWNER.) Практически само собой разумеется, мы не предоставляем привилегии PUBLIC, мы предоставляем роли, где это необходимо.
Я упоминаю об этом, потому что это шаблон, который мы используем для реализации принципа "наименьших привилегий".
Что касается других вопросов безопасности, я рекомендую вам ознакомиться с техническим документом «Oracle Security Checklist»:
http://www.oracle.com/technology/deploy/security/database-security/pdf/twp_security_checklist_database.pdf
Некоторые другие возможные исключения, с которыми вы могли столкнуться при выполнении оператора GRANT:
ORA-01031: insufficient privileges
или
ORA-04042: procedure, function, package, or package body does not exist.
В любом из этих случаев убедитесь, что вы подключаетесь к базе данных как SYS (SYSDBA) для предоставления привилегий. Мы почти всегда предоставляем привилегии как владелец объекта, а не как какой-то другой пользователь в качестве ГРАНТИТЕЛЯ. Я почти никогда не использую «WITH GRANT OPTION» для привилегий объекта. Это более простая модель, позволяющая избежать любой потенциальной проблемы с деревьями зависимостей.