То, что любой пользователь (роль) может передать свои права любому другому пользователю, является дыркой в безопасности. По логике это должен делать только администратор. Есть ли какой-то прикладной смысл того, зачем это было сделано? Можно ли как-то защититься от этого, кроме как включения логов, как это сделали вы в видео?
Спасибо, хорошее замечание. Это исправили в 15-й версии. По умолчанию роль больше не имеет ADMIN OPTION для самой себя. Что с одной стороны не дает возможность включить в себя другие роли, с другой стороны исключить себя из тех ролей, куда включил суперпользователь. Учтем при обновлении курса, но пока так.
когда пытаюсь подключиться к роли алиса, у меня запрашивает какой то пароль, но не пароль от виртуальной машины ни пароль, который задавался при установке постгрес не подходит. что делать?
Когда делаем grant dba to alice; мы даем права которые есть в роли dba алисе (как это сделано в oracle) или просто добавляем alice в группу dba? Далее, чтобы alice воспользоваться правами которые есть у dba нужно обязательно сделать SET ROLE? Или при grant они автоматом добавятся к alice?
Мы добавляем alice в группу dba, что приводит к тому, что права автоматически наследуются. Права не добавляются непосредственно к alice, но и SET ROLE делать не нужно. Есть нюансы: у alice должен быть атрибут INHERIT (он есть по умолчанию), иначе права не будут наследоваться.
Добрый день, господа. Подскажите, пожалуйста, по следующему моменту: получается, что если у роли отобрать её права, то она все ещё может пользоваться ими до окончания сеанса (либо до перезагрузки сервера)? Или существует какая-либо команда для полной блокировки пользователя? Что необходимо предпринять если в случае внештатной ситуации нам потребовалось отключить какого-либо пользователя и отнять все права? Для примера: мой bob, в своем терминале, после лишения его всех прав, продолжал смотреть представления, создавать таблицы без явного указания начала операции, а если и начинал их при помощи BEGIN (имея полномочия роли), то удачно завершал при помощи COMMIT, когда полномочия уже были отозваны, а это для него, по идее, уже запрещённые процедуры. На всякий случай попробовала перечитать файлы конфигурации (дабы не перезагружать сервер) - bob не реагировал. И пока я не перезагрузила сервер, bob (ну естественно я в данной роли) так и продолжал свои "манипуляции". Даже когда я удалила все его таблицы, а после этого полностью удалила роль с именем bob - он продолжал смотреть данные из базы в виде представлений (правда таблицы создавать уже не мог). Это "тонкое место", или я придаю этому слишком большое значение? Существует ли какой-то способ полностью заблокировать роль, кроме перезагрузки сервера (как я понимаю это крайне нежелательная процедура, если к серверу есть подключения )? В документации ответ на свой вопрос я не нашла. Заранее спасибо!
Дело в том, что сеанс использует локальный кеш системного каталога. Поэтому какие-то изменения могут доходить до него не сразу. Если вам действительно надо немедленно заблокировать пользователя, найдите его сеансы и завершите их (pg_terminate_backend).
access_roles=# CREATE ROLE alice LOGIN CREATEROLE; CREATE ROLE access_roles=# \c - alice; connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: FATAL: Peer authentication failed for user "alice" Previous connection kept why is that?
It's because of "peer" authentication mode for local connections in pg_hba.conf. For this mode to work, you have to declare name mapping; see postgrespro.com/docs/postgrespro/15/auth-username-maps Simpler way is to change authentication mode from "peer" to e.g. "trust" (just for convenience; don't do it in production).
@@PostgresProfessional я использую postgreSQL через docker, и когда подключаюсь к контейнеру и вхожу через psql в terminale, то могу динамически изменять текущего пользователя как в уроке. А вот через pgadmin4 не получается так же выводит authentiction failed. Это pgadmin может работать только с одним пользователем или нужно что-то менять в pg_hba.conf? И как менять pg_hba.conf через docker?
САМОЕ ЛУЧШЕЕ ВИДЕО ПО POSTGRES!
шикарные лекции, спасибо!
Спасибо!
Спасибо, а когда продолжение ждать?
Скоро будет, идет монтаж.
одна из самых простых тем...
Спасибо за видео. А как сделали презентацию в терминале? Какую программу использовали?
Это gotty.
То, что любой пользователь (роль) может передать свои права любому другому пользователю, является дыркой в безопасности. По логике это должен делать только администратор. Есть ли какой-то прикладной смысл того, зачем это было сделано? Можно ли как-то защититься от этого, кроме как включения логов, как это сделали вы в видео?
Спасибо, хорошее замечание. Это исправили в 15-й версии.
По умолчанию роль больше не имеет ADMIN OPTION для самой себя. Что с одной стороны не дает возможность включить в себя другие роли, с другой стороны исключить себя из тех ролей, куда включил суперпользователь.
Учтем при обновлении курса, но пока так.
@@pavelluzanov1188 Спасибо, что написали об этом в комментариях. Я уже подумал, что что-то делаю не так...
когда пытаюсь подключиться к роли алиса, у меня запрашивает какой то пароль, но не пароль от виртуальной машины ни пароль, который задавался при установке постгрес не подходит. что делать?
Когда делаем grant dba to alice; мы даем права которые есть в роли dba алисе (как это сделано в oracle) или просто добавляем alice в группу dba? Далее, чтобы alice воспользоваться правами которые есть у dba нужно обязательно сделать SET ROLE? Или при grant они автоматом добавятся к alice?
Мы добавляем alice в группу dba, что приводит к тому, что права автоматически наследуются. Права не добавляются непосредственно к alice, но и SET ROLE делать не нужно.
Есть нюансы: у alice должен быть атрибут INHERIT (он есть по умолчанию), иначе права не будут наследоваться.
Добрый день, господа. Подскажите, пожалуйста, по следующему моменту: получается, что если у роли отобрать её права, то она все ещё может пользоваться ими до окончания сеанса (либо до перезагрузки сервера)? Или существует какая-либо команда для полной блокировки пользователя? Что необходимо предпринять если в случае внештатной ситуации нам потребовалось отключить какого-либо пользователя и отнять все права? Для примера: мой bob, в своем терминале, после лишения его всех прав, продолжал смотреть представления, создавать таблицы без явного указания начала операции, а если и начинал их при помощи BEGIN (имея полномочия роли), то удачно завершал при помощи COMMIT, когда полномочия уже были отозваны, а это для него, по идее, уже запрещённые процедуры. На всякий случай попробовала перечитать файлы конфигурации (дабы не перезагружать сервер) - bob не реагировал. И пока я не перезагрузила сервер, bob (ну естественно я в данной роли) так и продолжал свои "манипуляции". Даже когда я удалила все его таблицы, а после этого полностью удалила роль с именем bob - он продолжал смотреть данные из базы в виде представлений (правда таблицы создавать уже не мог). Это "тонкое место", или я придаю этому слишком большое значение? Существует ли какой-то способ полностью заблокировать роль, кроме перезагрузки сервера (как я понимаю это крайне нежелательная процедура, если к серверу есть подключения )? В документации ответ на свой вопрос я не нашла. Заранее спасибо!
Дело в том, что сеанс использует локальный кеш системного каталога. Поэтому какие-то изменения могут доходить до него не сразу.
Если вам действительно надо немедленно заблокировать пользователя, найдите его сеансы и завершите их (pg_terminate_backend).
Когда второй курс будет ?
Работаем над обновлением.
access_roles=# CREATE ROLE alice LOGIN CREATEROLE;
CREATE ROLE
access_roles=# \c - alice;
connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: FATAL: Peer authentication failed for user "alice"
Previous connection kept
why is that?
It's because of "peer" authentication mode for local connections in pg_hba.conf. For this mode to work, you have to declare name mapping; see postgrespro.com/docs/postgrespro/15/auth-username-maps
Simpler way is to change authentication mode from "peer" to e.g. "trust" (just for convenience; don't do it in production).
@@PostgresProfessional спасибо большое. Мне просто было лень переключать раскладку, поэтому на английском написал
@@PostgresProfessional я использую postgreSQL через docker, и когда подключаюсь к контейнеру и вхожу через psql в terminale, то могу динамически изменять текущего пользователя как в уроке. А вот через pgadmin4 не получается так же выводит authentiction failed. Это pgadmin может работать только с одним пользователем или нужно что-то менять в pg_hba.conf? И как менять pg_hba.conf через docker?