So I know in postgres a group is nothing but a role. But I'll still use groups here.
Say I created a group called my_group as superuser.
I am user user_1.
I want to give user_1 permission to add more users into my_group.
What is the command I need to do as superuser to do that?
Use GRANT WITH ADMIN OPTION to do that:
GRANT my_group TO user_1 WITH ADMIN OPTION;
More info here.
Related
We have a scenario where some users would need super user permissions and other db users dont need it. So we have create the users and then created a role 'SuperRole' which has permissions to create role, db.
Let's say I have user 'User1' mapped to role 'User1' by default with INHERIT. After creating 'SuperRole' role I have ran
GRANT superrole to user1;
After this if I see \du output
postgres=# \du user1
List of roles
Role name | Attributes | Member of
--------------+------------------------+--------------
user1 | Create role, Create DB | {superrole}
As per the documentation https://www.postgresql.org/docs/11/role-membership.html the privileges of role 'member of' should also be inherited. But when i connect to psql with user1, I should be having the privileges of superrole also to create role and db. However when I try to create a db I am getting the below error.
postgres=> create database test;
ERROR: permission denied to create database
The similar error shows for creating role as well. What should be done to make the privileges set for superrole to be available for user1 as well.
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.
refer: https://www.postgresql.org/docs/current/role-membership.html
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.
In searching for examples of ALTER and GRANT commands I notice there are times where superuser is granted, but login is not.
Moreover, it turns out that if you GRANT SELECT privileges to a role but not LOGIN, they can't execute select queries anyway as it depends on login.
So what would be the use for a nologin superuser, or indeed a nologin role full stop? Is the only reason when the role is used as a group?
There are two things a role can do even if it cannot login:
It can own objects.
It can have other roles as members, that is, it can act as a user group.
As far as I can tell, a superuser owner only makes a difference with functions that are declared SECURITY DEFINER. Such functions run in the context of the functions's owner, that is, with superuser privileges. Powerful, but dangerous.
Being a member of a superuser role allows you to assume superuser privileges temporarily by issuing
SET ROLE the_su_role;
You can return to be a mortal user with
RESET ROLE;
That can be useful if you want to be able to issue superuser commands, but don't want to expose yourself to the risk of using a superuser all the time, similar to the su and sudo commands on UNIX.
I'm new to Google Cloud SQL. I created two postgres DBs with two new users (one created from web dashboard and one created from commandline). My goal is to prevent the two users to be able to modify each other DB, but I cannot get it to work.
Here is what I want:
UserA all privileges on DB_A
UserA no privileges on DB_B
UserB all privileges on DB_B
UserB no privileges on DB_A
I already tried to grant/revoke permissions from psql prompt, but in the end I still be able to create/drop tables in DB_A as UserB.
Is it possible to achieve what I want? Am I missing something?
Postgres on Cloud SQL is standard Postgres, so it's just like any other Postgres instance:
To give a role all privileges:
GRANT ALL ON <db_name> TO <role_name>;
To remove all privileges:
REVOKE ALL ON <db_name> TO <role_name>;
The Postgres docs on privileges does give the follow caveat for:
The special privileges of an object's owner (i.e., the right to modify
or destroy the object) are always implicit in being the owner, and
cannot be granted or revoked
So keep that in mind - if UserA owns both databases, they can always modify them.
I have created a ROLE with name Admin and I have given it all accesses (including CREATEDB). I have created a User ekekakos who is member of Admin role and inherints from it. When I am trying to create a new DB with ekekakos I am getting the following message:
ERROR. PERMISSION DENIED TO CREATE DATABASE.
When I enable the option CAN CREATE DB to the user ekekakos, the database is created.
Why the user do not take the privilages of the role Admin?
Thanks
Excerpt from the docs:
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.