Início / dba / Perguntas / 53914
Accepted
if __name__ is None
Asked: 2013-11-26 09:08:36 +0800 CST

Permissão negada para relação <table>

  • 772

Eu executei o seguinte SQL no psql:

CREATE USER bspu LOGIN;

CREATE DATABASE bsp OWNER bspu;

GRANT ALL PRIVILEGES ON DATABASE bsp TO bspu;

\c bsp

CREATE TABLE users (
  id SERIAL PRIMARY KEY,
  client_id VARCHAR(20) NOT NULL,
  api_key VARCHAR(100) NOT NULL,
  api_secret VARCHAR(100) NOT NULL,
  auth_token VARCHAR(128) NOT NULL
);

Quando faço login como bspue tento consultar a userstabela, recebo o erro:

permission denied for relation users

Tentei executar:

ALTER DEFAULT PRIVILEGES GRANT ALL ON TABLES TO bspu;

Mas isso não ajuda. O que estou fazendo errado? Por que o proprietário do banco de dados NÃO tem permissões para consultar seu próprio banco de dados?

EDIT: atualizei bspupara superusuário por enquanto, para poder continuar trabalhando. Qualquer orientação adicional apreciada.

postgresql permissions

3 respostas

  1. Best Answer

    DEFAULT PRIVILEGESnão altere as permissões para objetos existentes . Eles são os privilégios padrão para objetos recém-criados e apenas para a função específica a que pertencem. Se você não especificar a função ao executar ALTER DEFAULT PRIVILEGES, o padrão será a função atual (ao executar a ALTER DEFAULT PRIVILEGESinstrução.

    Além disso, como você está usando uma serialcoluna, que cria um SEQUENCE, convém definir também os privilégios padrão para as sequências.

    Execute isso no usuário com o qual você cria objetos, antes de executar o CREATEcomando:

    ALTER DEFAULT PRIVILEGES [ FOR ROLE my_create_role] GRANT ALL ON TABLES TO bspu;
ALTER DEFAULT PRIVILEGES [ FOR ROLE my_create_role] GRANT ALL ON SEQUENCES TO bspu;

    Uma palavra de cautela para os usuários do pgAdmin. Há um bug em todas as versões do pgAdmin III e pgAdmin4 (incluindo v5.3). O script SQL de engenharia reversa para os nós do banco de dados ou do esquema é exibido DEFAULT PRIVILEGESignorando o usuário proprietário e, portanto, está incorreto em determinadas situações. Relatei o bug (repetidamente) , mas o projeto encontrou dificuldades para corrigi-lo. pgAdmin III foi descontinuado em favor de pgAdmin4. O bug ainda está lá no pgAdmin4.

    Para objetos existentes , você também pode estar interessado nesta forma de "lote" do GRANTcomando :

    GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO bspu;
GRANT ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA public TO bspu;

    Mais sob esta pergunta relacionada no SO:

    • 41 
  2. This is working for me after some research. psql (9.6.12)

-- login to postgres database server as postgres user.
ssh <user>>@hostname.<domain>>.com
sudo su postgres
id
psql
postgres=# create user sentry_read with login password 'sentry_read';
postgres=# du+
postgres=# \l+
-- **very important: make sure we should connect required database before we grant to user.**
postgres=# \c sentry
postgres=# \dt
sentry=# \dp SENTRY_VERSION
sentry=# select * from "SENTRY_VERSION";
sentry=# GRANT SELECT ON ALL TABLES IN SCHEMA public TO sentry_read;
postgres=# \q

[user@hostname ~]$ psql -U sentry_read -d sentry -h hostname.<domain>>.com -W
sentry=> select * from "SENTRY_VERSION";
    • 0

  3. Se o erro

    ERROR:  permission denied for relation migrations

    aparece ao tentar fazer uma GRANT ACTION,

    example:GRANT SELECT ON ALL TABLES IN SCHEMA schema_name to ro_user;

    garantir que a GRANT seja realizada pelo usuário proprietário das respectivas tabelas. O proprietário dos esquemas pode variar em um banco de dados. Mesmo o usuário postgres não terá permissão para fornecer este acesso GRANT.

    • 0

relate perguntas