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.
Related
I'm trying to give an entire database access to a user, but remove access for a specific table or a specific schema that has confidential data, but it's just not working out, tried multiple - grant and revoke statements but in vain.
This is what I've tested so far.
Initially, I had this role for the user
GRANT ALL ON DATABASE raw TO ROLE transformer;
checked the grants and removed that
SHOW GRANTS TO ROLE transformer;
revoke select on all tables in schema raw.<secret_schema> from role transformer;
revoke all on DATABASE raw from ROLE transformer;
Started giving access to individual schemas/tables, but the "grant usage on database" just gives every schema/table access to the user
grant usage on database raw to role transformer ; -- usage gives all tables access
grant usage on schema raw.<open_schema> to role transformer ;
grant all on schema raw.<open_schema> to role transformer ;
grant select on all tables raw.<open_schema> to role transformer ;
Lastly, tried these revoke too, but in vain
revoke select on table raw.<secret_schema>.s from ROLE transformer;
revoke usage on schema raw.<secret_schema> from role transformer;
For more information, this access is for a DBT user and an analyst user, who can hit/select/read the raw database , but just 1 schema/table should not be accessible, rest all should be with a "future tables" clause.
Design deep-dive: https://blog.getdbt.com/how-we-configure-snowflake/
As Greg, already mentioned (and demonstrated), "GRANT ALL ON DATABASE raw TO ROLE x" does not grant permission to access the objects in the database. It grants permission to modify the database object (in your case, it's not needed and I would suggest you not grant it according to the "Principle of least privilege").
https://docs.snowflake.com/en/user-guide/security-access-control-privileges.html#database-privileges
I think, the confusing thing is, "revoke from" command does not return any error if you try to revoke permission that was not granted:
create role r2;
revoke all on database gokhan_db from role r2;
So your revoke commands do not fail, but in fact, they do not revoke anything, as this permission were assigned to the role public:
revoke select on table raw.<secret_schema>.s from ROLE transformer;
revoke usage on schema raw.<secret_schema> from role transformer;
Could you check the permissions of the role public, again?
show grants to role public;
grant usage on database raw to role transformer ; -- usage gives all
tables access
This is not what's granting access to the tables; something else is. You can confirm that running a simple script like this one:
use role securityadmin;
create role new_role_1;
grant role new_role_1 to user my_user;
use role sysadmin;
grant usage on database test to role new_role_1;
use role new_role_1;
select * from test.public.foo; --SQL compilation error: Object 'TEST.PUBLIC.FOO' does not exist or not authorized.
use role sysadmin;
select * from test.public.foo; -- Works
Roles inherit from other roles. All roles inherit from the PUBLIC role by default. Could someone have granted the PUBLIC roles the privileges that this role is inheriting? Does it inherit from a role that has more permissions than PUBLIC?
I would like to create "read-only privileges" in a PostgreSQL database (including the restriction of creating or dropping tables).
My strategy is to create a group with these privileges and then add roles that have had all their privileges revoked. In that way, the only inherit privileges when part of the read-only group.
I used the following commands to create privileges but it seems roles can add, delete tables when they join the group:
role_test_db=# REVOKE ALL ON DATABASE role_test_db FROM select_access_group;
REVOKE
role_test_db=# GRANT CONNECT ON DATABASE role_test_db TO select_access_group;
GRANT
role_test_db=# GRANT SELECT ON ALL TABLES IN SCHEMA public TO select_access_group;
GRANT
I was reading the documentation and it seems like creating tables would be under CREATE privilege but I have not granted this. Can some explain why users part of this group can still make tables?
There are several mistakes:
Revoking privileges on the database does not restrict user's rights to create objects. For that, you have to revoke privileges on the schemas.
You can only REVOKE privileges that were GRANTed (by default or explicitly). I doubt that select_access_group has ever been granted any privileges on the database.
You likely forgot to revoke the dangerous default CREATE privilege on schema public. Connect as superuser and run
REVOKE CREATE ON SCHEMA public FROM PUBLIC;
A user can only revoke privileges that were granted directly by that user
https://www.postgresql.org/docs/13/sql-revoke.html
See privileges
\du
select * from pg_roles;
Change (base) prilileges under admin role (postgres)
I cannot change any permissions in one of my db2 databases because the db2 instance is not authorized
DB21034E The command was processed as an SQL statement because it was not a
valid Command Line Processor command. During SQL processing it returned:
SQL0551N The statement failed because the authorization ID does not have the
required authorization or privilege to perform the operation.
I tried to grant administrative permissions for that user but it doesn't have grant permissions either
Do you know any command to check which users have permissions to that database?
Regards
If you know the password for the instance-owner (e.g. db2instx) for connecting to the database, or if you can su/sudo to the instance-owner on the Db2-server, then that instance owner account can grant other users the dbadm (and some other) database rights, and the user with SECADM role can grant additional permissions.
This is not a programming question, but instead an administration question, and the Db2 documentation covers this topic well. So do your study.
Refer to the documentation for details of the GRANT (database) statement
Also study the GRANT statement for table/views
along with other types of GRANT statement for other types of objects.
Study the role of SECADM, if such a role is defined, if your Db2-server version is modern. If your site uses ROLES in addition to other security mechanisms, you also need to be familiar with those.
To find your own account rights you can either query the catalog views (if you have permission, such as (syscat.tabauth, syscat.dbauth and others tc.) or call the table function AUTH_LIST_AUTHORITIES_FOR_AUTHID from the CLP after connecting.
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.
I'm not a DBA and I have got some questions around access controls for schemas. Let's say I have a Postgres server running a several databases. The admin user is postgres. I have another user tmpUser with which I could log in to the remote server using pgadmin3 client.
I now create a database called myDatabase which is by default owned by the postgres user. I then use my admin client to remotely log in to this myDatabase using the tmpUser account.
I now create a new schema inside this myDatabase called myDbSchema. I created a new role called myDbRole and did a grant usage, grant all on myDatabase, myDbSchema to the myDbRole.
The question now is how should I control access to this myDatabase. I tried to log in to the remote server using the tmpUser and when I tried to execute select * from myTable where myTable is a table in myDatabase, it came back with a permission denied sql message. So I changed the owner of the table to the tmpUser which I really do not want to!
Is there a guide or something on how I should go about creating and organizing roles with schemas in postgres?
It is not entirely clear what your problem is (for instance, what is role "myDbRole" for, is that a group role (NOLOGIN) or a user role (LOGIN)?) but in general you could follow this pattern of permission management:
Create a specific role to own a database and all or most of the objects in it. This should be a group role (NOLOGIN) for security reasons. Do not use the postgres user; if you need to login as that role often to do regular database work, you are doing something wrong. Any superuser (or other user role that has that role granted to it) can "impersonate" that owner role using SET SESSION AUTHORIZATION to do necessary maintenance. In a production environment this should be hardly ever necessary; during development you might want to consider making the role with LOGIN permission for ease of use.
The owner creates all the schemas, tables, views, functions, etc. that you need for your application. By default, all of those objects are only available to the database owner, with the exception of functions.
Define a number of group role profiles, each having specific requirements of the database. You could have, for instance sales_staff, product_managers, accounting and senior_management for a company, or web_user, web_admin, app_developer and app_manager for a web site. The database owner then GRANTs access to the database (CONNECT), schemas (USAGE), tables, views and functions (EXECUTE), as needed. I usually REVOKE ALL ON FUNCTION x() TO public, for security reasons.
Assign group role membership to user roles, as needed: GRANT sales_staff TO jane. The user roles should have LOGIN INHERIT such that they can log in and inherit the permission of group roles that they are a member of. That includes the permission to connect to a database and usage rights on schemas. Note that a single user role can have membership in multiple group roles.
Lastly, update your pg_hba.conf file to enable remote access to the database.