Create Read only user

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Create Read only user

Yambu
Hello

I created a user like this 

CREATE USER user1 WITH PASSWORD '<password>';

GRANT CONNECT ON DATABASE db1 TO user1;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO user1;

What amazes me is that when I connect using user1, I'm able to create a table and drop it. How can this be?



Reply | Threaded
Open this post in threaded view
|

Re: Create Read only user

Rohit Rajput
By default, every user has permission to do anything on public schema. Because users are created outside of databases here. If you want to users not to have any permission when those are created, use this:

REVOKE ALL ON SCHEMA public FROM PUBLIC;

and now provide permissions what you want to specific users.

GRANT ALL/SELECT/.... ON SCHEMA public to your_user;


Cheers
On Friday, 22 January, 2021, 02:29:31 pm IST, Yambu <[hidden email]> wrote:


Hello

I created a user like this 

CREATE USER user1 WITH PASSWORD '<password>';

GRANT CONNECT ON DATABASE db1 TO user1;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO user1;

What amazes me is that when I connect using user1, I'm able to create a table and drop it. How can this be?



Reply | Threaded
Open this post in threaded view
|

Re: Create Read only user

Tim Cross
In reply to this post by Yambu

Yambu <[hidden email]> writes:

> Hello
>
> I created a user like this
>
> CREATE USER user1 WITH PASSWORD '<password>';
>
> GRANT CONNECT ON DATABASE db1 TO user1;
> GRANT SELECT ON ALL TABLES IN SCHEMA public TO user1;
>
> What amazes me is that when I connect using user1, I'm able to create a
> table and drop it. How can this be?

In PG, all users by default have access to a PUBLIC schema as well as
their user schema. The schema is really public, so full access to
create/drop tables etc. The search path determines which schemas are
searched and the search order.

I rarely use the PUBLIC schema for an application. While you can revoke
access at various levels, it often has unexpected consequences because
different users may have different expectations with respect to the
PUBLIC schema and what access users have.

To have tables and other objects where you explicitly manage the access
by users, your best bet is to create an application specific schema. You
can then set the default grant permissions on that schema and its
objects without fear of impacting on other users and manage access
rights how you see fit. In fact, for more complex applications, I might
have multiple schemas. In addition to enabling more flexible access
control, schemas can also make it easier to backup, restore and migrate
data between environments.

Some people don't like using schemas because they don't like having to
prefix object names with the schema name, but I find this is often a
sign of not using the path and search_path settings appropriately.
Personally, I prefer to be explicit and specify the schema rather than
relying on individual configuration and setup of login profiles.




--
Tim Cross


Reply | Threaded
Open this post in threaded view
|

Re: Create Read only user

Holger Jakobs-2
Yes, the PUBLIC schema is a remnant from times when no schemas were
used, but all table were created in the database itself. This was the
case in the early 7.x versions.

There are still some applications around which have no notion of a
schema. This is especially true for those which are expected work with a
bunch of very weak database servers, for instance with MySQL.
MySQL/MariaDB only have schemas and just a single database per server
instance. They call their schemas databases, though.

If you have an application which is made to run with PostgreSQL, the
configuration will allow to specify a schema to put the tables into.

Otherwise, you'll have to set up a search path including the schema you
want the database objects to end up in. You can configure the default
search path for the application user appropriately using ALTER ROLE.

Hardly any application forces the PUBLIC schema to be around. It's just
that the PUBLIC schema exists in the template1 database with full access
to PUBLIC and thus will exist in every database you create, unless you
remove it (or change the access rights) in the template1 database. And
the default search path includes PUBLIC.

Actually, this only exists to be compatible with *very* old applications.

Regards,

Holger

--

Holger Jakobs, Bergisch Gladbach, Tel. +49-178-9759012



OpenPGP_signature (209 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Create Read only user

Wells Oliver-2
Is there any weird unexpected downside to revoking perms on PUBLIC from all my users? It drives me nuts the random stuff that fills this schema up, even after I got everyone their own shiny personal schema.

On Fri, Jan 22, 2021 at 12:09 PM Holger Jakobs <[hidden email]> wrote:
Yes, the PUBLIC schema is a remnant from times when no schemas were
used, but all table were created in the database itself. This was the
case in the early 7.x versions.

There are still some applications around which have no notion of a
schema. This is especially true for those which are expected work with a
bunch of very weak database servers, for instance with MySQL.
MySQL/MariaDB only have schemas and just a single database per server
instance. They call their schemas databases, though.

If you have an application which is made to run with PostgreSQL, the
configuration will allow to specify a schema to put the tables into.

Otherwise, you'll have to set up a search path including the schema you
want the database objects to end up in. You can configure the default
search path for the application user appropriately using ALTER ROLE.

Hardly any application forces the PUBLIC schema to be around. It's just
that the PUBLIC schema exists in the template1 database with full access
to PUBLIC and thus will exist in every database you create, unless you
remove it (or change the access rights) in the template1 database. And
the default search path includes PUBLIC.

Actually, this only exists to be compatible with *very* old applications.

Regards,

Holger

--

Holger Jakobs, Bergisch Gladbach, Tel. +49-178-9759012




--
Wells Oliver
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Create Read only user

Ron-2
In reply to this post by Holger Jakobs-2
On 1/22/21 2:09 PM, Holger Jakobs wrote:
[snip]
> Actually, this only exists to be compatible with *very* old applications.

And new applications written by people who don't know this, and so put all
their tables in public.

--
Angular momentum makes the world go 'round.


Reply | Threaded
Open this post in threaded view
|

Re: Create Read only user

Tom Lane-2
In reply to this post by Wells Oliver-2
Wells Oliver <[hidden email]> writes:
> Is there any weird unexpected downside to revoking perms on PUBLIC from all
> my users? It drives me nuts the random stuff that fills this schema up,
> even after I got everyone their own shiny personal schema.

As far as the system is concerned, no; in fact you could drop PUBLIC
altogether if you like.  Your users might whine though...

(Actually, dropping it altogether might be a bad idea, because then
it will come back in your next upgrade.  I think that if you just
change the permissions on it, modern versions of pg_dump/pg_upgrade
will propagate that successfully.)

                        regards, tom lane