подскажите, пожалуйста, можно ли определенному пользователю или группе убрать доступ на синоним?

есть селект, где в качестве таблиц для выборки указаны системные таблицы state и user владельца IBS и со схемы аудита AUD таблица IBS_OSH через синоним OBJECT_STATE_HISTORY

можно ли сделать как-то так, чтобы на синоним у конкретного пользователя прав не было?

11.2.0.3

ElicOzornitcaможно ли сделать как-то так, чтобы на синоним у конкретного пользователя прав не было?Синонимы не являются субъектом раздачи прав.

а как-нибудь можно сделать так, чтобы конкретный пользователь не смог работать с этим синонимом?

запретить , привилегию или грант какой

совершенно пока в этом не понимаю

tru55Если синоним создан как PUBLIC, то он по любому доступен всем пользователям. Если синоним создан как приватный (в схеме конкретного пользователя), то он доступен только этому пользователю.
Кроме того, доступ к таблице определяется не синонимом, а грантами на таблицу. Можно видеть синоним, но получить ORA-942, если у данного пользователя нет прав доступа к таблице.

таблица в схеме другого владельца , мы работаем с владельцем IBS, а таблица в схеме аудита с владельцем AUD

нельзя поэтому оперировать доступом на таблицу, на которую синоним

а нельзя на синоним паблик запретить доступ ? у запретов же приоритет выше, чем у разрешений ?

ViewerSheriffuaOzornitca,
посмотрите здесь
Ozornitcaтаблица в схеме другого владельца , мы работаем с владельцем IBS, а таблица в схеме аудита с владельцем AUD
нельзя поэтому оперировать доступом на таблицу, на которую синоним
Пока вообще непонятно, какие возможности (права) что либо делать есть у топикстартера в базе.
Возможно, если хочется скрыть логику доступа, достаточно "завернуть" использование синонима во вьюшку, с последующй раздачей на неё прав.

вот именно такая мысль и была, но хотелось бы как-нибудь попроще сделать :)

всем кто ответил- огромное спасибо, я почитаю отпишусь

пока просто совершенно плаваю в этом вопросе, ниче не понимаю

tru55Ozornitcaа нельзя на синоним паблик запретить доступ ? у запретов же приоритет выше, чем у разрешений ?
А где ты видел в Oracle запреты?
Есть


но нет



revoke, deny...

нет?

SheriffuaOzornitca,

посмотрите здесь

ссылку посмотрела, описывается безопасность на уровне строк,

нам же надо , чтобы была не видна вся таблица, на которую синоним

andrey_anonymous,

у нас owner IBS, а от него доступ через выдается остальным

а теперь как-то может IBS как owner запретить доступ определенному пользователю на свой синоним?

andrey_anonymousНе очень понятно из описания чего конкретно пытаетесь добиться.
Но если вдруг стандартная модель грантов oracle по каким-то причинам недостаточна - есть FGAC
https://docs.oracle.com/cd/B19306_01/network.102/b14266/apdvpoli.htm#i1008306

написано тоже про доступ к отдельным строкам

tru55,
я писала выше, что таблица в схеме с другим владельцем (схема аудита AUD , а мы работаем в схеме с владельцем IBS), администрировать доступ там нет возможности

с этой таблицей в принципе можно работать только через синоним,

или вьюшку делать

или можно раздать права на схему с другим владельцем?

Q.TarantinoOzornitcaможно ли сделать как-то так, чтобы на синоним у конкретного пользователя прав не было?
с аудитом в данной системе работает определенная группа лиц, сами знаете кто это.
зачем забирать то?
и, ежели стоит конкретная задача - что вам ответило ЦФТ? Вы хоть спрашивали?

не спрашивала , тк смысла нет
1 линия там никакая,
может помочь если только кто-то с сайта цфт-клуба

Q.TarantinoOzornitcaможно ли сделать как-то так, чтобы на синоним у конкретного пользователя прав не было?
с аудитом в данной системе работает определенная группа лиц, сами знаете кто это.
зачем забирать то?
и, ежели стоит конкретная задача - что вам ответило ЦФТ? Вы хоть спрашивали?

задача на интерес, так скзать
с таблицами из схемы аудита работают абсолютно все, при просмотре некоторой информации по документам,например через синоним как сейчас

andrey_anonymousOzornitcaс этой таблицей в принципе можно работать только через синоним,
или вьюшку делать
или можно раздать права на схему с другим владельцем?

...смешались в кучу кони, люди...
Ozornitca, вообще говоря, security - дело тонкое, требует определенной квалификации.
А у Вас пока даже задачу внятно сформулировать не получается.
Может, более опытных коллег привлечете?

Что понятно:
- Схема IBS содержит некую таблицу (пусть - TAB)
Или не IBS, а AUD... Если AUD - то при чем тут owner IBS?
- Где-то существует некий синоним к таблице (IBS?AUD?).TAB
Все остальное - загадочная загадка.
- Должен ли доступ быть предоставлен конкретной схеме Oracle или, скажем, пользователю домена windows?
- Какой именно доступ? Только Select или dml тоже нужен? На все строки или по какому-то критерию?
- При чем тут вообще синоним, как он влияет на доступ?

спасибо за внимание к моему вопросу (выше кстати писала, в какой схеме какие таблицы находятся), повторюсь, чтобы вы не тратили свое время на поиск и ваш скептицизм очень подкованного в этих вопросах человека не рос:
1) селект из трех таблиц, две из которых находятся в схеме с владельцем IBS (user и state) и одна IBS_OTCH в схеме с владельцем AUD, в которую селект обращается со схемы IBS через синоним OBJECT_STATE_HISTORY (отсюда было сообщение про owner IBS, тк овнер синонима IBS)

2) доступ нужен только на select , на все строки

3) в селекте обращаются не к самой таблице. которая в схеме с другим владельцем, а через синоним

на все вопросы ответила ?
я правда пока не разбираюсь в доступе oracle, буду благодарна за терпение и понимание :)

Q.TarantinoOzornitca1 линия там никакая,
может помочь если только кто-то с сайта цфт-клуба
а причем тут первая линия? у вас саппорт и закрепленные сопровожденцы.
и это... у вас пользователи работают под IBS???
скажите название банка, плиз. я буду обходить его стороной :)

никто не работает под IBS, каждый пользователь работает под своим пользоватлеем в системе

вы издеваетесь специально ? или до сих пор не поняли, что результатом выборки select * from dba_synonyms where synonym_name = 'OBJECT_STATE_HISTORY' стало:

OWNER SYNONYM_NAME TABLE_OWNER TABLE_NAME DB_LINK
1 IBS OBJECT_STATE_HISTORY AUD IBS_OSH


извините, но если вы будете обходить стороной с таким непонятным отношением и очень странными предположениями о том, что все пользователи работают под владельцем схемы, то думаю, нам это будет плюс.

хорошего дня

Q.Tarantinoandrey_anonymousЧто понятно:
- Схема IBS содержит некую таблицу (пусть - TAB)
Или не IBS, а AUD... Если AUD - то при чем тут owner IBS?
- Где-то существует некий синоним к таблице (IBS?AUD?).TAB
насколько помню, владелец таблицы - AUD
в схеме IBS есть синоним на эту таблицу.

а вот чего хочет добиться ТС, я так и не понял.
ТС, ты хочешь чтобы у IBS не было прав на данный синоним?

я хочу , чтобы у пользователя, который запускает такой селект, не было доступа на таблицу, на которую указывает синоним

а вот каким образом от IBS права переданы этому пользователю, если на синоним права не раздаются- не могу понять

прошу прощения, там ошибка в названии таблицы, не IBS_OTCH, а IBS_OSH (на схеме AUD)

JonhsonQ.TarantinoТС, ты хочешь чтобы у IBS не было прав на данный синоним?

читаю тему и взрывает мозг, что такое права на синоним?

а ничего что можно явно указать схему и наплевать на синонимы?

можно было бы, если бы была возможность править код
а в данный момент код закрыт для правки (делать можно только очень ограниченные доработки)

поэтому возник вопрос, можно ли как-то разрешить этот вопрос доступом

FogelOzornitca3) в селекте обращаются не к самой таблице. которая в схеме с другим владельцем, а через синоним

Выше уже несколько раз пояснили, что такое утверждение ошибочно.
Если есть права у юзера1 на таблицу юзера2, то вне зависимости от наличия синонима, юзер 1 получит данные юзера 2.
Если нет прав, но есть синоним, то юзер1 просто увидит синоним, но получить данные не сможет - получит ошибку.

Вам надо, чтобы оунер таблицы (юзер2) забрал права у юзера 1 на те операции, которые недоступны.

хорошо,
как можно забрать права на таблицу со схемы с другим владельцем. Конкретную команду можете подкинуть?

Q.Tarantino,
пользователям, которые выполняют этот селект с синонином, овнером которого является IBS (а каким образом организованы права, тут у меня знаний не хватает)

это и пытаюсь понять сейчас

Fogelв вашем случае из-под пользователя AUD (или привиллегированного, например из группы DBA)



выполнила команду под sysdba
revoke select on AUD.IBS_OSH from IT;

результат:
ORA-01927: нельзя изъять привилегии, т.к. Вы не имеете на это права

задача на самом деле на собственный интерес,

давно спрашивали, я не нашла как сделать,
а сейчас появилась свободная минутка, захотелось разобраться

andrey_anonymousOzornitca1) селект из трех таблиц, две из которых находятся в схеме с владельцем IBS (user и state) и одна IBS_OTCH в схеме с владельцем AUD, в которую селект обращается со схемы IBS через синоним OBJECT_STATE_HISTORY (отсюда было сообщение про owner IBS, тк овнер синонима IBS)

2) доступ нужен только на select , на все строки

3) в селекте обращаются не к самой таблице. которая в схеме с другим владельцем, а через синоним

на все вопросы ответила ?
я правда пока не разбираюсь в доступе oracle, буду благодарна за терпение и понимание :)

Ок, продолжаем формулировать задачу.
Имеем три таблицы:
IBS.USER
IBS.STATE
AUD.IBS_OSH

Требуется ограничить доступ к этим таблицам - разрешить только select ко всем строкам.

Кому следует разрешить доступ?

- Конкретному пользователю oracle?
- Конкретному приложению , работающему от имени пользователя Oracle (какого? IBS?)
- Кому-то еще?

Когда будете отвечать на эти вопросы, подумайте - как данные попадают в эти таблицы и как повлияет на работу системы запрет их модификации.

1) требуется ограничить доступ только к таблице AUD.IBS_OSH на селект
2) конкретному пользователю oracle (для примера взяла пользователя своего- IT)

3) по последнему абзацу - конкретному пользователю запрет только на селект, пользователь не является тем, кто в принципе может что-то записывать в базу, он просмотровый