Re: privileges oddity

Поиск
Список
Период
Сортировка
От Adrian Klaver
Тема Re: privileges oddity
Дата
Msg-id 99994f76-5a45-09a1-c6e3-4021cb4bd385@aklaver.com
обсуждение исходный текст
Ответ на Re: privileges oddity  (Scott Ribe <scott_ribe@elevated-dev.com>)
Ответы Re: privileges oddity  (Scott Ribe <scott_ribe@elevated-dev.com>)
Список pgsql-general
On 8/7/20 11:56 AM, Scott Ribe wrote:
>> On Aug 7, 2020, at 12:45 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>
>> If I'm reading this correctly, you have set things up so that any
>> session logging in as akanzler will immediately do "SET ROLE
>> confidential_read_only", after which it's the privileges of that
>> role not akanzler that determine what happens.
> 
> YES, confidential_read_only has privs on everything *except* individual user's schemas, and rolinherit was
accidentallyset, that would certainly seem to be the problem. But I turned that off, and it still doesn't work--even in
anew connection.
 
> 

https://www.postgresql.org/docs/12/sql-set-role.html

"Using this command, it is possible to either add privileges or restrict 
one's privileges. If the session user role has the INHERIT attribute, 
then it automatically has all the privileges of every role that it could 
SET ROLE to; in this case SET ROLE effectively drops all the privileges 
assigned directly to the session user and to the other roles it is a 
member of, leaving only the privileges available to the named role. On 
the other hand, if the session user role has the NOINHERIT attribute, 
SET ROLE drops the privileges assigned directly to the session user and 
instead acquires the privileges available to the named role.
"


-- 
Adrian Klaver
adrian.klaver@aklaver.com



В списке pgsql-general по дате отправления:

Предыдущее
От: Scott Ribe
Дата:
Сообщение: Re: privileges oddity
Следующее
От: Scott Ribe
Дата:
Сообщение: Re: privileges oddity