How to get/change db2 database owner?
In DB2 there is no direct database owner, but there is the concept of database administrator. Here is an overview of DB2 database authorities. Those are per database and can be granted and revoked. In order to get or change the "database owner" you would revoke the DBADM authority or grant it. You could even have multiple users who have that authority.
All users with DBADM authority can be obtained this way:
SELECT DISTINCT GRANTEE, GRANTEETYPE FROM SYSCAT.DBAUTH
WHERE DBADMAUTH = 'Y'
In order to create a database, you would need the SYSADM or SYSCTRL authority on the system (instance) level.
In DB2 that is one of the strangest things, to take care of that, after restore you have to run following command and recycle the instance which causes outage.
db2set DB2_RESTORE_GRANT_ADMIN_AUTHORITIES=ON
This may not be ideal if the instance where you restore the DB is sort of cannot take outage. So avoid this situation as part of instance setup I set this variable to begin with.
Related
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.
We have a production postgres database which is accessible by all team members.
We use pgadmin to administer the database.
For safety reasons, I am willing to make the database readonly. So that, only data can be viewed and cannot be modified
(blocking any update operation to the database).
If any database update is required, then I can make the database to readwrite mode, make the modification
and change to readonly again.
There are ROLES AND PRIVILEGES options which can be used for achieving this functionality.
But I am wondering if there is any Pgadmin UI options for making the database readonly.
Thanks in advance.
Why don't you use Roles and Privileges ??
create multiple users
master_user
readonly_user
etc
Once you have users created, you can grant access on database/ schema or even table level.
Share the readonly user with the team and keep the master user for admins / applications etc
More info on postgres roles and privileges: https://www.postgresql.org/docs/current/user-manag.html
Chapter 21. Database Roles lists the default roles of PostgreSQL. But I don't find user postgres there,
which has been created by default in PostgreSQL. Is postgres a
default role? Does the manual miss it or do I misunderstand?
In PostgreSQL, is postgres a special user, or a regular user just
like one created manually? Does the PostgreSQL server need the user postgres? Will removing it cause some trouble to the server or something else?
The following two commands run in psql provide default roles or
usernames, which both include postgres. Why do they differ?
# select usename from pg_catalog.pg_user;
usename
----------
postgres
(1 row)
# select rolname from pg_catalog.pg_roles;
rolname
----------------------
postgres
pg_monitor
pg_read_all_settings
pg_read_all_stats
pg_stat_scan_tables
pg_signal_backend
(6 rows)
postgres is not a default role.
When you create the PostgreSQL database cluster with initdb, you can specify the name of the installation superuser with the -U option. If you omit that option, the name of the superuser will be the same as the name of the operating system user you are using.
Since it is customary to have initdb PostgreSQL run by an operating system user postgres, the superuser is usually called postgres too, but that isn't in any way required.
postgres is just a normal superuser like any other.
You will have trouble dropping it because it owns all the system objects, and you cannot easily modify those objects. You are advised not to try.
pg_read_all_settings and the others don't show up in pg_user because they are not login roles.
postgres is the first user that is available after an installation. it is a super user. But, it is possible to define your own super users which will have equivalent permissions to the postgres user.
A user is a role that has the ability to log in.
Roles without login privilege are used for various system level uses and are sometimes also used to manage access control rules through inheritance (e.g. you may have a role analysts and a user hal that is granted membership to the analysts role)
Thus pg_user only returns those roles that are able to log into the database.
I have a funny question about PostgreSQL database: What happens if the postgres database is dropped?
dropdb postgres worked.
createdb postgres worked too.
psql worked.
But I thought the users would be lost. Yet the old users are still there.
So where are the users stored for the database and which implications does dropping the postgres database have?
PostgreSQL metadata are stored in catalog tables, which are in the pg_catalog schema. These are accessible like regular views and tables.
There are shared system catalog tables which are shared between all databases. These tables are not affected when databases are dropped.
pg_authid, the table where the users are stored, is one of those shared catalogs. This is because in PostgreSQL, users don't belong to a database, but to the whole database cluster.
You can list all shared catalog tables like this:
SELECT relname FROM pg_class
WHERE relisshared AND relkind = 'r';
In the documentation you can find more information about the system catalogs.
When connecting to a Postgres server, you always need to specify which database you want to connect to.
When you set up a new server, you need something to connect to before you can run your first CREATE DATABASE statement.
That's all the postgres database is: a dummy database to use as a connection target for admin commands. There's no data in there, and you're free to drop it and use a different one instead (though whoever inherits your system will probably not thank you for it...).
As gil.fernandes said in his answer, server-wide objects like users are accessible from every database, but aren't stored inside any database in particular.
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.