Postgresql: o que GRANT ALL PRIVILEGES NO DATABASE faz?

Question

Estou tentando conceder todos os privilégios em todas as tabelas de um determinado banco de dados para um novo usuário postgres (não o proprietário). Parece que GRANT ALL PRIVILEGES ON DATABASE my_db TO new_user; não faz isso. Depois de executar o comando com sucesso (como o usuário postgres), recebo o seguinte como new_user:

$ psql -d my_db
my_db => SELECT * FROM a_table_in_my_db;
ERROR:  permission denied for relation a_table_in_my_db

Duas perguntas:

1) O que o comando acima faz, então, se não conceder todas as permissões em todas as tabelas no my_db?

2) Qual é a maneira correta de conceder todas as permissões em todas as tabelas para um usuário? (incluindo todas as tabelas criadas no futuro)

    

Answer 1

As respostas às suas perguntas vêm dos documentos on-line do PostgreSQL 8.4 .

1. GRANT ALL PRIVILEGES ON DATABASE concede os privilégios CREATE , CONNECT e TEMPORARY em um banco de dados a uma função (os usuários são adequadamente chamados de papéis ). Nenhum desses privilégios permite uma função para ler dados de uma tabela; O privilégio SELECT na tabela é necessário para isso.

2. Não sei se existe uma maneira "adequada" de conceder todos os privilégios em todas as tabelas a uma função. A melhor maneira de garantir que uma determinada função tenha todos os privilégios em uma tabela é garantir que a função possua a tabela. Por padrão, cada objeto recém-criado é de propriedade da função que o criou, portanto, se você quiser que uma função tenha todos os privilégios em uma tabela, use essa função para criá-la.

   O PostgreSQL 9.0 introduz a seguinte sintaxe que é quase o que você quer:

   GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO new_user;

   O problema é que, se você criar tabelas em esquemas fora do esquema "público" padrão, esse GRANT não se aplicará a eles. Se você usar esquemas não públicos, terá de GRANT os privilégios para esses esquemas separadamente.

Answer 2

É possível configurar vários logins para atuar como o proprietário do banco de dados:

• Crie uma função "nologin" para atuar como o proprietário: create role dbowner nologin
• Altere o proprietário do banco de dados para este: alter database mydb owner dbowner
• Conceda todos os seus logins para essa nova função: grant dbowner to user1, user2

Agora, se o usuário1 ou o usuário2 fizerem login, eles terão todas as permissões em "mydb" sem necessidade de outros subsídios.

No entanto, eu consideraria essa solução com cuidado. É tentador fazer com que seu aplicativo da Web use um desses logins para evitar a dificuldade de criar concessões adicionais sempre que o esquema for atualizado, mas você está removendo uma forma muito útil de proteção dessa maneira. Use a solução acima se você realmente quiser vários "admins", mas fique com o padrão "conceder todos os privilégios em todas as tabelas no esquema ..." acima para o login da sua aplicação "uso normal".