I am using PostgreSQL as my database along with Prisma as my ORM.It seems to be giving an issue while running the 'prisma migrate' command on the server which seems to be an issue of user database privileges not being present.What are the basic user privileges that are required for Prisma while using Postgres apart from the option of giving full admin rights?
Database user needs to have a CREATEDB privilege for using migrate commands in PostgreSQL.
Here's a reference to privileges needed for each supported database: Reference.
Related
I get from customer Postgres 8.4, a very strange edition
I login with Postgres user under trust settings.
But in pgAdmin i got a lot of relations errors
I thought normally tables should goes to DB Catalogs Tables, but here DB Catalogs Tables not exists or i cant see them, all tables i see in db Schemas, and database is working as i can access it through ODBC and Postgres connector, but then i see all 2809 tables i a row without separation. It like multi tenat services, but misconfigured or not suit with pgAdmin.
From pgAdmin i cant create any user and roles, from ssh psql created user cant connect through odbc or Postgres connector, and do not appears in pgAdmin Login/Group Roles tab.
So why i cant access in pgAdmin4 Login/Group Roles tab?
Why cant create user from pgAdmin4?
Why cant access pg_catalogs from pgAdmin4?
Why user created from ssh psql cant access database from ODBC or Postgres connector? (got always table is empty)
If this is multi tenant services why it not work like expected from pgAdmin?
PgAdmin 4 version 5.6
PgAdmin4 says it supports 9.5 and newer. 8.4 is not newer than 9.5.
I've just set up Postgres for use by different users on my network. Every user has his own username/password/database, but when I connect to Pg I can also see a 'postgres' database (and even create tables etc). I tried to REVOKE access to that database from public but then it won't let me connect. What exactly is the postgres database and why is it needed? Can I disable it so that users only see the database(s) I've created for them?
The postgres database is created by default when you run initdb.
Quote from the manual:
Creating a database cluster consists of creating the directories in which the database data will live (...) creating the template1 and postgres databases. When you later create a new database, everything in the template1 database is copied. (...) The postgres database is a default database meant for use by users, utilities and third party applications.
There is nothing special about it, and if you don't need it, you can drop it:
drop database postgres;
You need to do that as a superuser of course. The only downside of this is that when you run psql as the postgres operating system user, you need to explicitly provide a database name to connect to
If you drop the postgres database you'll find a few things to be confusing. Most tools default to using it as the default database to connect to, for one thing. Also, anything run under the postgres user will by default expect to connect to the postgres database.
Rather than dropping it, REVOKE the default connect right to it.
REVOKE connect ON DATABASE postgres FROM public;
The superuser (usually postgres), and any users you explicitly grant rights to access the database can still use it as a convenience DB to connect to. But others can't.
To grant connect rights to a user, simply:
GRANT connect ON DATABASE postgres TO myuser;
A fresh installation of PostgreSQL 9.3 (according to the YUM Installation manual on the PostgreSQL wiki) on CentOS 6 (64-bit) will not grant permissions to any users.
I log in to the postgres user and open psql, then I create a role for my default user:
CREATE ROLE <name> WITH PASSWORD '<password>';
and then try to grant it privileges on the default postgres database:
GRANT ALL ON DATABASE postgres TO <user>;
which gives the expected output, but the user does not have any permissions on postgres.
The output of \dp <user> is quizically empty as well. Additional testing shows that I cannot give any users permissions. However, when I try to drop a role that has been granted these nonexistent permissions, it says
ERROR: role "<user>" cannot be dropped because some objects depend on it
DETAIL: privileges for database postgres
I am at a loss. I did also check to make sure the postgres Linux user has the appropriate file permissions on the PostgreSQL data directory.
Presumably you're expecting too much of GRANT ALL ON DATABASE postgres TO <user>;
ALL in this context means that the command is equivalent to:
GRANT CREATE,CONNECT,TEMPORARY ON DATABASE postgres TO <user>;
And the way you create the ROLE, it cannot login to any database anyway (you can check this with \du).
It could if it was created with:
CREATE ROLE name WITH LOGIN PASSWORD 'pass';
or use ALTER ROLE name WITH LOGIN later on.
Starting from this, to give the user permissions to create objects in the database, other forms of GRANT should be used.
I'd puzzled, being a newbie to postgresql.
I have a database named "Launch"
I'm running:
GRANT ALL PRIVILEGES ON DATABASE Launch TO admin;
user admin has privileges like:
Additionally, running postgres command:
\list
yields the database "Launch"
The only thing I did see was, there was no entry for "Access Privileges" for the database Launch:
What am I doing wrong here?
Lesson learned the long way:
GRANT ALL PRIVILEGES ON DATABASE <yourdbhere> TO <youruserhere>;
the <yourdbhere> the db name MUST be in lower case. By using Launch for my db name - it was messing things up.
I have a backup of database (IBM DB2 v. 9.7)
After restore command I cannot access some of the tables due to privileges issues.
On the original db client and database we have a user: userx with admin privileges and on the new db client we have a usery also with admin privileges.
restore is done but I cannot access the database tables
Can somebody explain me what is the problem
thank you
In version 9.7, authorities like DBADM do not have data access privilege, because of the separation of duties. This is granted via SECADM.
Check the authorizations via the authorizations view: http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.sql.rtn.doc/doc/r0022658.html
Check the priviles granted to "userX" and mimic those privileges to "usery".