In Google's SQL Cloud Postgres service, when I create a database via the Web Console for a PostgreSQL instance, it automatically sets the owner of the database's default "public" schema to be cloudsqladmin. It seems I cannot change the ownership:
mydb=> \dn
List of schemas
Name | Owner
--------+---------------
public | cloudsqladmin
(1 row)
mydb=> alter schema public owner to postgres;
ERROR: must be owner of schema public
mydb=> \du
List of roles
Role name | Attributes | Member of
-------------------+------------------------------------------------+---------------------
cloudsqladmin | Superuser, Create role, Create DB, Replication | {}
cloudsqlagent | Create role, Create DB | {cloudsqlsuperuser}
cloudsqlreplica | Replication | {}
cloudsqlsuperuser | Create role, Create DB | {}
pg_signal_backend | Cannot login | {}
postgres | Create role, Create DB | {cloudsqlsuperuser}
mynewuser | Create role, Create DB | {cloudsqlsuperuser}
I also created a "mynewuser" through the web console, and cannot remove the "mynewuser" from the "cloudsqlsuperuser" group:
mydb=> alter group cloudsqlsuperuser drop user mynewuser;
ERROR: "cloudsqlsuperuser" can't be altered
If I wanted to create a database with a public schema that only a new user has access to (and owns), should I be doing this outside of the Google web ui? It seems like any databases I create are owned by cloudsqladmin, and any users I create are those "cloudsqlsuperuser" members. If I wanted to restrict permissions for a user, should I create that user normally via psql and bypass the web ui altogether?
From my experience, you seem to have to bypass the web ui / cli tool entirely.
When you create a database through the cli tool:
gcloud sql databases create DBNAME --instance INSTANCE
It assigns ownership to cloudsqlsuperuser, same as through the gui from the sounds of it.
When I have created a user specifically through the CLI tool:
gcloud sql users create USER 'host' --instance INSTANCE
Those users get the same permissions as cloudsqlsuperuser. In this case, it is possible to alter the ownership of the database. I had success through psql command connecting as the user I wanted to own the database and running:
ALTER DATABASE database OWNER TO user;
However if the user was created via psql (not glcoud cli), then the permission are not the same and the above failed.
I'd be tempted to create your instance, set the 'postgres' users password through the tool, then psql into the instance from there and do everything you need via sql commands. I think the tool does some things very nicely (as does the UI), but its a pain later on.
If anyone knows better, I'd love to hear how you can work with the default gcloud user.
Basically what happens here is that a usual CREATE DATABASE statement seems to create a new database based on the template0 database. This database is owned by cloudsqladmin. A role only Google has access to. When the gcloud or web GUI is used, it executes the following query:
CREATE DATABASE mydb TEMPLATE template1;
For template1 the owner is set to cloudsqlsuperuser a role that gets assigned to the postgres user, and other users created through the GUI.
So if you would like to create a database using sql with the appropriate privileges, just execute the statement above, and your public schema will then be owned by the cloudsqlsuperuser, and can be altered using the default postgres user, or other users created through the web GUI.
Connect to the database mydb by owner user (for exaple, it is mynewuser).
If you want to change the public schema owner, first you should make the user postgres owner of your database mydb:
mydb=> ALTER DATABASE mydb OWNER TO postgres;
After that, you can change the public schema owner:
mydb=> ALTER SCHEMA public OWNER TO postgres;
Besides, to remove your mynewuser from the cloudsqlsuperuser group (role) use:
mydb=> REVOKE cloudsqlsuperuser FROM mynewuser;
Note: The default postgres user in Google Cloud Platform's (GCP) Cloud SQL (PostgreSQL) is not a superuser of the instance. Also, all users created from the GCP web UI have cloudsqlsuperuser role by default, and the following attributes (privileges): CREATEROLE, CREATEDB and LOGIN. They don't have the SUPERUSER or REPLICATION attributes.
Related
this is happening on newly created Postgres 13 instance on GCP's Cloud SQL.
I would like to disallow users to CONNECT to newly created databases. So I am modifying template database:
REVOKE ALL ON DATABASE template1 FROM public;
Then, I create new Database:
CREATE DATABASE mydb TEMPLATE template1;
Then I am checking CONNECT permissions for existing user:
SELECT datname
FROM pg_database
WHERE has_database_privilege('someuser', datname, 'CONNECT')
datname
---------------
cloudsqladmin
postgres
template0
mydb
So as you can see someuser has CONNECT permission to mydb.
Why is this happening? How can I prevent users to connect to newly created databases?
The permissions on a database are not copied from the template database during CREATE DATABASE. Rather, all new databases have the same default permissions: CONNECT and TEMP for PUBLIC, and all permissions for the owner.
There is no way to change that default, short of modifying the PostgreSQL code.
I am using the PostgreSql manual and other guides to setup my database environment.
So far things are looking good, but I am wondering if I have a problem.
I am trying to apply this:
Tip It is good practice to create a role that has the CREATEDB and CREATEROLE privileges, but is not a superuser, and then use this role for all routine management of databases and roles. This approach avoids the dangers of operating as a superuser for tasks that do not really require it.
I have already created a user for this role.
createuser --interactive --pwprompt
Enter name of role to add: Manager
Enter password for new role:
Enter it again:
Shall the new role be a superuser? (y/n) n
Shall the new role be allowed to create databases? (y/n) y
Shall the new role be allowed to create more new roles? (y/n) y
...and connected to an already existing database as the new user (Manager) Or so I thought.
psql -d test
Password for user postgres:
psql (11.2)
WARNING: Console code page (437) differs from Windows code page (1252)
8-bit characters might not work correctly. See psql reference
page "Notes for Windows users" for details.
Type "help" for help.
test=# \c test Manager
Password for user Manager
WARNING: Console code page (437) differs from Windows code page (1252)
8-bit characters might not work correctly. See psql reference
page "Notes for Windows users" for details.
You are now connected to database "test" as user "Manager".
test=>
I created a table for the database "test", but on checking it,the Owner isn't Manager, but postgres.
test=> \dt
List of relations
Schema | Name | Type | Owner
--------+---------------+-------+----------
public | Data-projects | table | postgres
(1 row)
test=> \dn
List of schemas
Name | Owner
--------+----------
public | postgres
(1 row)
I am not sure if this is good. I expected the owner to be Manager.
This is my first time using these tools. Can someone guide me in the right direction, please?
I want Manager to manage all the databases.
Wouldn't that make him owner?
Thanks
Database test is not owned by Manager because it was created by user postgres. The user who created an object will be its owner.
However, a superuser can transfer ownership:
ALTER DATABASE test OWNED BY "Manager";
I'll give you some additional tips:
Only use lower case letters, numbers and _ in the names of objects and users, because otherwise you always have to user double quotes for them in SQL, like I did above. That leads to needless suffering.
Run the following to make the database more secure:
REVOKE CREATE ON SCHEMA public FROM PUBLIC;
Create a new schema that will hold the objects for your application:
CREATE SCHEMA myapp;
Set the search_path appropriately:
ALTER DATABASE test SET search_path = myapp, public;
After upgrading from postgresql 9.6 to 10.1-R1, the user do not have access to tables.
after investigation, I found the exact same issue on that post
When I look at my access privileges, it is empty:
\dn+
List of schemas
Name | Owner | Access privileges | Description
--------+----------+-------------------+------------------------
public | rdsadmin | | standard public schema
When it should be postgres=UC/postgres=UC/postgres
It was correctly set before migration
the recommendation was to run the command grant all on schema public to <my user>; but I don't have enough permission with RDS. Any recomendation to handle this with RDS?
I have the solution from the AWS forum.
First, run
ALTER SCHEMA PUBLIC OWNER TO <my rds_superuser>;
Then run the grant statement after:
grant all on schema public to <my user>;
I just created a new postgres RDS instace on aws (through the dashboard), and I gave it a default user, lets call him "jack".
When I logged in to the instance, I saw my created user "jack", and that he had a role "rds_superuser" attached. (so I thought that I can do the same things that I used to do with superuser on a regular postgres server).
I checked the documentation, I saw that wasn't possible.
As logged in as the default user "stan", I created a new database user like "stan", and wanted to create a new databases with the owner being the user "stan", I couldn't?
I entered something like this:
CREATE DATABASE foobar WITH OWNER = stan;
But I got an error, saying something like:
ERROR: must be member of role "stan"
So, what I did was, made the role "stan", logged out as the default user "jack", logged into the RDS instance as "stan", and created that database with him as the owner.
Since I had three different users, I had to repeat that last step three times.
My question, is there a way, that I can make the default user "jack" that I created during RDS postgres creation, capable of creating new databases (like superuser on a regular postgres server installation) and giving the different owners like this:
CREATE DATABASE foobar WITH OWNER = stan;
Tnx,
Tom
you were supposed to grant stan to rds_superuser in order to do that. You did:
rds=> create user stan;
CREATE ROLE
rds=> CREATE DATABASE foobar WITH OWNER = stan;
ERROR: must be member of role "stan"
you should:
rds=> grant stan to su_rdsadm;
GRANT ROLE
rds=> CREATE DATABASE foobar WITH OWNER = stan;
CREATE DATABASE
I did it as rds superuser:
rds=> \du+ su_rdsadm
List of roles
Role name | Attributes | Member of | Description
-------------+-------------------------------+----------------------+-------------
su_rdsadm | Create role, Create DB +| {rds_superuser,stan} |
| Password valid until infinity | |
rds=> select current_user;
current_user
--------------
su_rdsadm
(1 row)
It's good to know this further. This limitation of rds_superuser for ownership/grants and so on will keep hitting you until you grant role whose objects you want to manipulate (or on which behalf you want to grant) to rds superuser.
I'm sure I'm missing something simple, but I've created the following:
postgres=# \du
List of roles
Role name | Attributes | Member of
-----------+-----------------------------------------+-----------
admin | No inheritance, Create DB, Cannot login | {}
postgres | Superuser, Create role, Create DB | {}
wade | | {admin}
(Note that Cannot login and No inheritance don't affect what's happening to wade, here. See the PostgreSQL documentation for role membership to understand why. —bignose)
However, when I try to create a db, I get:
bin wwilliam$ createdb -U wade test
Password:
createdb: database creation failed: ERROR: permission denied to create database
What am I missing?
An excerpt from the manual:
The INHERIT attribute governs inheritance of grantable privileges (that is, access privileges for database objects and role memberships). It does not apply to the special role attributes set by CREATE ROLE and ALTER ROLE. For example, being a member of a role with CREATEDB privilege does not immediately grant the ability to create databases, even if INHERIT is set; it would be necessary to become that role via SET ROLE before creating a database.
(Emphasis mine).
In documentation:
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
So you must activate admin role using SET ROLE admin; before creating DB.