I created several login and group roles in pgadmin. I then added these login roles to their respective group roles. Then I give these group roles login privileges to a database as well as other required privileges.
But connecting to the database fails with "User does not have CONNECT privilege".
Then I grant login privileges directly to the login roles in pgsql, because pgadmin does not let me add privileges to login roles, only group roles.
Now the user is able to connect to the database, but still gets various privilege errors until I give privileges directly to the login role.
Is this a bug in PostgreSQL (v 9.4.5 for Windows), or what is going on here? I also tried to add privileges to group roles using pgsql instead of pgadmin, with same results.
CREATE ROLE user_g
NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE NOREPLICATION;
CREATE ROLE user_l LOGIN
ENCRYPTED PASSWORD 'md5...'
NOSUPERUSER NOINHERIT NOCREATEDB NOCREATEROLE NOREPLICATION;
GRANT user_g TO user_l;
GRANT ALL ON DATABASE db TO postgres;
GRANT CONNECT ON DATABASE db TO user_g;
REVOKE ALL ON DATABASE db FROM public;
Above statements do not give user_l privileges to connect to the database, but following does.
GRANT CONNECT ON DATABASE db TO user_l;
The problem then repeats for functions and everything else that requires privileges.
Related
Created a user/role via following method is Aurora Postgres:
CREATE ROLE rds_user_test;
GRANT rds_superuser to rds_user_test;
GRANT rds_iam TO rds_user_test;
When I login using IAM DB Auth as rds_user_test it appears that I can do all operations as needed except creating or altering roles (maybe other functionality is missing but haven't tested all operations yet). When I check role memberships of this new role against other roles that are able to create/alter roles, both are members of superuser.
I also followed the instructions here:
https://aws.amazon.com/premiumsupport/knowledge-center/rds-aurora-postgresql-clone-master-user/
Still get the same permissions error:
[42501] ERROR: permission denied to create role
Any thoughts on why this new role cannot create/alter other roles even though it seems to have the same privileges of superuser as other roles?
rds_superuser on Amazon Aurora is typically not a superuser. Check with:
SELECT rolsuper FROM pg_roles WHERE rolname = 'rds_superuser';
But to create a role, you don't need superuser privileges. All you need is the CREATEROLE privilege. Check if your user has that:
SELECT rolcreaterole FROM pg_roles WHERE rolname = 'rds_user_test';
Else you need to grant it (as a role that's allowed to do so):
ALTER ROLE rds_user_test CREATEROLE;
Any role with the CREATEROLE privilege can do that (typically including rds_superuser).
The manual:
Roles having CREATEROLE privilege can change any of these settings except SUPERUSER, REPLICATION, and BYPASSRLS; but only for non-superuser and non-replication roles.
The instructions you followed, explicitly instruct to add CREATEROLE, you seem to have skipped that bit:
CREATE ROLE new_master WITH PASSWORD 'password' CREATEDB CREATEROLE LOGIN;
On google cloud, with "postgres" user (which is not superuser), i do:
CREATE ROLE postgres_subuser1 LOGIN PASSWORD 'some_pass';
CREATE ROLE postgres_subuser2 LOGIN PASSWORD 'some_pass';
GRANT postgres TO postgres_subuser1;
GRANT postgres TO postgres_subuser2;
Above part wroks, though then I try to set users access on each other objects:
ALTER DEFAULT PRIVILEGES FOR ROLE postgres_subuser1 GRANT ALL PRIVILEGES ON TABLES TO postgres_subuser2;
ALTER DEFAULT PRIVILEGES FOR ROLE postgres_subuser2 GRANT ALL PRIVILEGES ON TABLES TO postgres_subuser1;
gives: must be member of role "postgres_subuser1"
How can solve that?
BTW, if try same on local instance, it works without any error, but this error raises on google cloud.
You need to explicitly grant the postgres user the role. Eg:
GRANT postgres_subuser1 TO postgres;
I am working with Firebird 2.5.8, ODS Version 11.2, connecting via Firebird ADO.NET v6.6 (in C# using Visual Studio). I have built a database management tool for configuring our tables, as well as performing some basic Firebird user management operations. The database has different roles (MyRoleX and MyRoleY) defined to give/restrict access.
User management operations include granting/revoking these roles to different users. When logged into the tool, the connection uses the RDB$ADMIN ROLE and the connected user has been created with the ADMIN ROLE. Lastly, there may be more than one Firebird user of the tool (e.g. Mgr1 and Mgr2).
Ok, so Mgr1 CREATEs a new user, along with:
GRANT MyRoleX TO UserA;
GRANT MyRoleY TO UserA;
Mgr1 then is off shift/vacation/unavailable, and Mgr2 realizes UserA should not have been granted MyRoleY. But when Mgr2 logs in and tries to run the command:
REVOKE MyRoleY FROM UserA;
the error message is given:
unsuccessful metadata update
Mgr2 is not grantor of Role on MyRoleY to UserA.
and if the command is changed to:
REVOKE MyRoleY FROM UserA GRANTED BY Mgr1;
then an error message is given:
unsuccessful metadata update
Only SYSDBA or database owner can use GRANTED BY clause.
While the 2nd message is explicitly clear, why, if both Mgr1 and Mgr2 are connected using ROLE=RDB$ADMIN (and of course these users are granted ADMIN ROLE), can they NOT perform this operation?
From Statements for Revoking Privileges , under the heading 'Revoking Privileges That Were GRANTED BY' it states:
the current user must be logged in either with full administrative privileges
If logged in under under RDB$ADMIN, is that not full admin privileges?
At the top of the link under the heading 'RDB$ADMIN Role', it also states:
Assigning the RDB$ADMIN role to a regular user in a database grants that user the privileges of the SYSDBA.
So why then does Mgr2 have privilege like SYSDBA?
Some questions seeking answers:
Am I doing anything wrong here? Is there a way to connect or allow Mgr2 to REVOKE GRANTs to ROLEs made by Mgr1?
We do NOT want to be sharing the SYSDBA nor database owner credentials to perform these operations, so any other solutions?
Since Firebird 2.5.9 Release Notes do not mention any user grant related bugfixes, I think you mistook something, probably you just did not invoke the RDB$ADMIN when you logged in with Mgr2. Try querying the active role just before trying to revoke.
Just tried this in Firebird 2.5.9 Win64 using IBExpert suite.
First session:
/*** connected as SYSDBA with no role specified ***/
GRANT RDB$ADMIN TO ADM_1;
GRANT RDB$ADMIN TO ADM_2;
CREATE ROLE USER_ROLE;
Second session:
/***** ADM_1 with RDB$ADMIN role specified *****/
select current_role, current_user from rdb$database;
-- ROLE USER
-- RDB$ADMIN ADM_1
grant user_role to user_1;
grant user_role to user_2 granted by sysdba;
Third session:
/***** ADM_2 with RDB$ADMIN role specified *****/
select current_role, current_user from rdb$database;
-- ROLE USER
-- RDB$ADMIN ADM_2
revoke user_role from user_2 granted by sysdba;
-- OK
revoke user_role from user_1;
-- This operation is not defined for system tables.
-- unsuccessful metadata update.
-- ADM_2 is not grantor of Role on USER_ROLE to USER_1.
revoke user_role from user_1 granted by adm_1;
-- OK
So, at least in 2.5.9 SuperServer with a single connection to the database - it just works.
P.S. since you can have many more admins than just two, and since SEVERAL admins may grant a role to the user, and then EACH of those grants would have to be found and revoked one by one, so I suggest for your scenario you have a dedicated user then, with all grants being given in his name, like I did with SYSDBA in my second session.
I am aware that similar questions have been asked before, but the answers do not appear to solve my problem, so I think a more complete answer would be valuable.
I would like to create a read-only user for a postgresql database. I have already granted access to the server for my user using the pg_hba.conf file.
As the postgres admin user, I have run the following commands:
CREATE ROLE read_only_user NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE NOREPLICATION;
GRANT CONNECT ON DATABASE the_database TO read_only_user;
GRANT USAGE ON SCHEMA public to read_only_user;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO read_only_user;
GRANT SELECT ON ALL SEQUENCES IN SCHEMA public TO read_only_user;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO read_only_user;
ALTER ROLE read_only_user WITH PASSWORD '*********************';
ALTER ROLE read_only_user VALID UNTIL 'infinity';
ALTER ROLE read_only_user WITH LOGIN;
ALTER USER read_only_user SET search_path = public;
As a result, I am able to log in to the the_database DB locally, and remotely using a DB client, with username and password authentication and I can list the tables in the database. However, any attempt to select or view the contents of the database results in
ERROR: permission denied for relation the_table
What other permissions are needed, since as far as I can tell, all the necessary permissions are granted.
I ran into a very annoying role inheritance issue with PostgreSQL. It simply doesn't behave as it should according to the documentation.
I would like to have a master role, and grant its permissions to newly created users. These users should inherit the permissions without issuing SET ROLE manually.
CREATE ROLE testrole NOSUPERUSER INHERIT CREATEDB NOCREATEROLE;
CREATE ROLE testuser LOGIN NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE;
GRANT testrole TO testuser;
Now after I connect as testuser, I get the following:
postgres=> CREATE DATABASE foobar;
ERROR: permission denied to create database
postgres=> SET ROLE testrole;
SET
postgres=> CREATE DATABASE foobar;
CREATE DATABASE
According to the docs linked above (because of the INHERIT option), the SET ROLE shouldn't be required.
What am I missing here?
A bit further down the same page:
"The role attributes LOGIN, SUPERUSER, CREATEDB, and CREATEROLE can be thought of as special privileges, but they are never inherited as ordinary privileges on database objects are. You must actually SET ROLE to a specific role having one of these attributes in order to make use of the attribute."