Re: privileges oddity

Поиск
Список
Период
Сортировка
От Adrian Klaver
Тема Re: privileges oddity
Дата
Msg-id d756080b-88d2-8793-a4a6-079c039bdfb8@aklaver.com
обсуждение исходный текст
Ответ на Re: privileges oddity  (Scott Ribe <scott_ribe@elevated-dev.com>)
Ответы Re: privileges oddity  (Adrian Klaver <adrian.klaver@aklaver.com>)
Список pgsql-general
On 8/7/20 12:27 PM, Scott Ribe wrote:
>> On Aug 7, 2020, at 1:08 PM, Adrian Klaver <adrian.klaver@aklaver.com> wrote:
>>
>> "Using this command, it is possible to either add privileges or restrict one's privileges. If the session user role
hasthe INHERIT attribute, then it automatically has all the privileges of every role that it could SET ROLE to; in this
caseSET ROLE effectively drops all the privileges assigned directly to the session user and to the other roles it is a
memberof, leaving only the privileges available to the named role. On the other hand, if the session user role has the
NOINHERITattribute, SET ROLE drops the privileges assigned directly to the session user and instead acquires the
privilegesavailable to the named role.
 
>> "
> 
> So it would only have removed privs if I had used set role in the session, which I am not.
> 

See Tom's answer. To confirm do:

SELECT
     s.setdatabase,
     s.setrole,
     rolname,
     s.setconfig,
     rolname
FROM
     pg_db_role_setting AS s
     JOIN pg_roles AS r ON r.oid = s.setrole;

-- 
Adrian Klaver
adrian.klaver@aklaver.com



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: privileges oddity
Следующее
От: Adrian Klaver
Дата:
Сообщение: Re: privileges oddity