It seems that when creating a new user, a default "USAGE" privilege is granted on EVERY database without any way to revoke these "usage" privileges.
steps to reproduce:
CREATE USER 'mynewuser'#'%'
IDENTIFIED BY 'xxx';
flush privileges;
then
SHOW GRANTS FOR 'mynewuser';
> GRANT USAGE ON *.* TO 'mynewuser'#'%'
Trying to revoke:
REVOKE USAGE ON *.* FROM 'mynewuser'#'%';
FLUSH PRIVILEGES;
SHOW GRANTS FOR 'mynewuser';
> GRANT USAGE ON *.* TO 'mynewuser'#'%'
Correct me if I'm wrong but I think you have an incorrect understanding of the USAGE privilege.
This privilege specifier stands for “no privileges.” It is used at the
global level with GRANT to modify account attributes such as resource
limits or SSL characteristics without naming specific account
privileges in the privilege list. SHOW GRANTS displays USAGE to
indicate that an account has no privileges at a privilege level.
Related
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.
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 created a new connection in Oracle SQL Developer. Under this new connection, I created a new user. Now, I'm trying to grant roles and System privileges to this new user. I get the following error while trying to grant system privileges to the new user:
The new user has been granted all the roles successfully. However, I'm unable to grant all system privileges to it.
UPDATE:
I followed this and this links to grant sysdba privilege to the new user using the command prompt. I'm able to grant sysdba to this new user. However, when I try to grant all system privileges from the Oracle sql Developer, I get the same error (specified in the screenshot above). I am trying to grant all the system privilege to the new user because I'm getting following error while trying to access the tables of the database.
Recently I had to change my OS to Windows 10. Earlier I had Windows 7 and I didn't have any of this issues. Is this issue related to OS? Is there any problem to use Oracle SQL Developer in Windows 10?
Please refer to this blog
The ORA-01031: "insufficient privileges" error occurs when you attempt
to execute a program or function for which you have not been granted
the appropriate privileges.
For the DBA, the ORA-01031 can happen if the target OS executables do
not have read and execute permissions (e.g. (770) in UNIX/Linux), and
ensure that the oracle user is a member of the dba group (e.g.
/etc/group). There are similar permission in the Windows registry.
Inside Oracle, the "ORA-01031: insufficient privileges" error can be
avoided by signing on "as sysdba" with unlimited database privileges.
The oerr utility notes this on the ORA-01031 error:
ORA-01031: insufficient privileges
Cause: An attempt was made to change the current username or password
without the appropriate privilege. This error also occurs if
attempting to install a database without the necessary operating
system privileges. When Trusted Oracle is configure in DBMS MAC, this
error may occur if the user was granted the necessary privilege at a
higher label than the current login.
Action: Ask the database administrator to perform the operation or
grant the required privileges. For Trusted Oracle users getting this
error although granted the appropriate privilege at a higher label,
ask the database administrator to re-grant the privilege at the
appropriate label.
You should be connected as SYS or SYSTEM in order to grant SYSDBA. Are you?
For example:
connect sys/pwd#db as sysdba
grant sysdba to santobedi;
Connect as sysdba
bash-4.2$ $ORACLE_HOME/bin/sqlplus / as sysdba
show user will show user as 'SYS'
show con_name will display CDB$ROOT
SQL> alter session set container=PDB19;
Session altered.
SQL> grant sysdba to ggadmin;
Grant succeeded.
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.