Thread: Grant all privileges to user on a database
Hi,
I am running postgresql15-server 15.3 on Red Hat Enterprise Linux
release 8.7 (Ootpa)
# rpm -qa | grep -i post
postgresql15-server-15.3-2PGDG.rhel8.x86_64
postgresql15-libs-15.3-2PGDG.rhel8.x86_64
postgresql15-15.3-2PGDG.rhel8.x86_64
#
$psql
psql (15.3)
Type "help" for help.
postgres=# GRANT ALL PRIVILEGES ON DATABASE cbdevdb TO cbdevdbadmin;
postgres=# \du
List of roles
Role name | Attributes
| Member of
--------------+------------------------------------------------------------+-----------
cbdevdbadmin | | {}
postgres | Superuser, Create role, Create DB, Replication, Bypass RLS | {}
postgres=#
Am I missing something? Please suggest. Thanks in advance.
Best Regards,
Kaushal
On 7/24/23 08:15, Kaushal Shriyan wrote:
> Hi,
>
> I am running postgresql15-server 15.3 on Red Hat Enterprise Linux
> release 8.7 (Ootpa)
>
> # rpm -qa | grep -i post
> postgresql15-server-15.3-2PGDG.rhel8.x86_64
> postgresql15-libs-15.3-2PGDG.rhel8.x86_64
> postgresql15-15.3-2PGDG.rhel8.x86_64
> #
>
> $psql
> psql (15.3)
> Type "help" for help.
>
> postgres=# GRANT ALL PRIVILEGES ON DATABASE cbdevdb TO cbdevdbadmin;
> postgres=# \du
> List of roles
> Role name | Attributes
> | Member of
> --------------+------------------------------------------------------------+-----------
> cbdevdbadmin | | {}
> postgres | Superuser, Create role, Create DB, Replication, Bypass RLS | {}
>
> postgres=#
>
> Am I missing something? Please suggest. Thanks in advance.
No, you aren't. Role attributes are not the same as table privileges.
--
Born in Arizona, moved to Babylonia.
On Mon, Jul 24, 2023 at 6:51 PM Ron <ronljohnsonjr@gmail.com> wrote:
>
> On 7/24/23 08:15, Kaushal Shriyan wrote:
> > Hi,
> >
> > I am running postgresql15-server 15.3 on Red Hat Enterprise Linux
> > release 8.7 (Ootpa)
> >
> > # rpm -qa | grep -i post
> > postgresql15-server-15.3-2PGDG.rhel8.x86_64
> > postgresql15-libs-15.3-2PGDG.rhel8.x86_64
> > postgresql15-15.3-2PGDG.rhel8.x86_64
> > #
> >
> > $psql
> > psql (15.3)
> > Type "help" for help.
> >
> > postgres=# GRANT ALL PRIVILEGES ON DATABASE cbdevdb TO cbdevdbadmin;
> > postgres=# \du
> > List of roles
> > Role name | Attributes
> > | Member of
> > --------------+------------------------------------------------------------+-----------
> > cbdevdbadmin | | {}
> > postgres | Superuser, Create role, Create DB, Replication, Bypass RLS | {}
> >
> > postgres=#
> >
> > Am I missing something? Please suggest. Thanks in advance.
>
> No, you aren't. Role attributes are not the same as table privileges.
>
>
> --
> Born in Arizona, moved to Babylonia.
>
>
Thanks Ron for the quick response and appreciate it. I am currently facing the below error while configuring the PostgreSQL 15.3 from Drupal CMS version 9.5.10 (https://www.drupal.org/project/drupal/) web interface.
Failed to CREATE a test table on your database server with the command CREATE TABLE {drupal_install_test} (id int NOT NULL PRIMARY KEY). The server reports the following message: SQLSTATE[42501]: Insufficient privilege: 7 ERROR: permission denied for schema public LINE 1: CREATE TABLE "drupal_install_test" (id int NOT NULL PRIMARY ... ^: CREATE TABLE "drupal_install_test" (id int NOT NULL PRIMARY KEY); Array ( ) .
Are you sure the configured username has the necessary permissions to create tables in the database?
Please suggest. Thanks in advance.
Best Regards,
Kaushal
On Monday, July 24, 2023, Kaushal Shriyan <kaushalshriyan@gmail.com> wrote:
Are you sure the configured username has the necessary permissions to create tables in the database?
The error message is misleading, you can’t directly create tables in a database, you must create them in a schema and the permission to do so is granted to the role on the schema, not the database.
David J.
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> The error message is misleading, you can’t directly create tables in a
> database, you must create them in a schema and the permission to do so is
> granted to the role on the schema, not the database.
The actual server message is going to be just
ERROR: permission denied for schema public
I'm not sure where the "Are you sure ..." bit came from, but it wasn't
Postgres.
Anyway, backing up two steps, it looks like drupal hasn't yet adapted
to the v15 change that removed default create privileges on the public
schema (for security reasons). You might see if a newer drupal release
is available. If not, the best bet would likely be
GRANT ALL ON SCHEMA public TO public;
If you run into more problems, a more drastic answer might be to
downgrade to whatever drupal considers a supported release of
Postgres.
regards, tom lane
On 7/24/23 09:09, Tom Lane wrote: > "David G. Johnston" <david.g.johnston@gmail.com> writes: >> The error message is misleading, you can’t directly create tables in a >> database, you must create them in a schema and the permission to do so is >> granted to the role on the schema, not the database. > The actual server message is going to be just > > ERROR: permission denied for schema public > > I'm not sure where the "Are you sure ..." bit came from, but it wasn't > Postgres. > > Anyway, backing up two steps, it looks like drupal hasn't yet adapted > to the v15 change that removed default create privileges on the public > schema (for security reasons). You might see if a newer drupal release > is available. If not, the best bet would likely be > > GRANT ALL ON SCHEMA public TO public; I'd have naively expected "GRANT ALL ON SCHEMA public TO public; " to be taken care of by "GRANT ALL PRIVILEGES ON DATABASE cbdevdb TO cbdevdbadmin;". -- Born in Arizona, moved to Babylonia.
On Mon, Jul 24, 2023 at 7:52 AM Ron <ronljohnsonjr@gmail.com> wrote:
On 7/24/23 09:09, Tom Lane wrote:
> GRANT ALL ON SCHEMA public TO public;
I'd have naively expected "GRANT ALL ON SCHEMA public TO public; " to be
taken care of by "GRANT ALL PRIVILEGES ON DATABASE cbdevdb TO cbdevdbadmin;".
I'm quite happy that such a command doesn't go ahead and grant read, write, and execute privileges on every table, function, and view in the database.
The thing that does what you describe is called SUPERUSER.
David J.