This is probably a silly question and I'm sure it's a problem with my mental model.
Ultimately I want to set privileges on a role such that any other roles in that role have CRUD access to all the current tables and automatically all of the future tables in perpetuity for said database. but ONLY those roles that have been explicitly added to said 'group role'.
It's not clear how to do this.
There is no way to get exactly what you want, but you can get close enough.
Dealing with existing tables is simple enough: just revoke all privileges that have been granted on the tables and grant access to your group role. The command that makes this easy is
GRANT/REVOKE ALL
ON ALL TABLES IN SCHEMA ... TO/FROM ...;
To deal with future tables, you'll have to restrict the circle of users that may create tables to a few, and for each of them run
ALTER DEFAULT PRIVILEGES FOR ROLE creating_user
GRANT ALL ON TABLES TO ...;
If you cannot enumerate the users that can create tables, an event trigger running at the end of each CREATE statement may be an alternative.
Related
I have multiple databases and each of them have multiple schemas.
I have a set of apps that connect to these databases. Each app has it own user and, depending on their function, the apps can:
read / write all schemas and tables of a specific db, set functions/notifications
read only all schemas and tables of a specific db
The schemas and tables can be created at any time, so the permissions need to be set with ALTER DEFAULT.
My understanding is that the ALTER DEFAULT has to be done by the user that will create the future tables. Is that correct?
Since I can have scenarios where User 1 can RO db A, but RW db B, while User 2 can only RO db B, etc.. using roles doesn't seem to be of any help here.
So I'm a bit confused how to set that up.
Then comes the next complication:
I can assign permissions as either SELECT (RO), or SELECT, INSERT, UPDATE, DELETE (RW), but:
what about sequences? I don't want a RW user to be able to alter the sequences, but they need to be able to use them
then how does it work with functions? the RW users need to be able to set/update their own functions
Any example of this setup would be greatly appreciated because going through the doc didn't help me much and most of the questions / answers on SO seems to be very similar yet never exactly the same, so it's quite confusing :)
Edit, following 'a_horse_with_no_name''s suggestion in the comments, I did this:
here is my init.sql:
CREATE DATABASE accounts;
CREATE DATABASE analysis;
CREATE DATABASE exchange;
GRANT CONNECT ON DATABASE exchange TO capture, analyzer, sunny, viewer;
GRANT CONNECT ON DATABASE analysis TO analyzer, sunny, viewer;
GRANT CONNECT ON DATABASE accounts TO sunny;
then I log in as admin to db exchange and do:
GRANT pg_write_all_data TO capture;
GRANT pg_read_all_data TO analyzer, sunny, viewer;
and I create a table called instruments there
then I log in as capture to to db exchange and do an insert, and I get:
42501: permission denied for table instruments
so using the capture user on the exchange db, I should have the pg_write_all_data property; why do I get the error?
It looks like I have to grant usage of instruments to capture.. which defeats the purpose of the pg_write_all_data. If I do the grant, then it works. So it looks like adding the role doesn't work.
Since your users shall have different permissions in different databases, define read-only and read-write roles for each database.
For example, db1_ro has read-only permissions in db1, and db2_rw has read-write permissions in db2. Then you can grant them both to a user, and the user will have different permissions in different databases.
Using a sequence typically means to call nextval(). So you should give that user the USAGE privilege. To use setval(), the user would need UPDATE. Nobody except the owner can ALTER an object anyway.
Functions cannot be set or updated, only executed, for which there is the EXECUTE privilege, which is granted to PUBLIC by default.
i'm new-ish to postgresql and wondering what are good patterns for securing objects in your databases.
i've been using MSFT SQL server for most of my career, and like the approach that they have taken to securing databases and objects. Some of the things that I'm missing in postgresql are pre-defined roles at the instance and database levels, such as db_reader and db_writer.
how do you handle security of new objects?
are you limiting peoples ability to create new objects within the database (of course you are, but i'm interested in an approach or patterns), and how are you doing that (using CICD, manually, event-based triggers)
Currently, i'm using a series of event-based triggers and roles to manage new object creation. I don't like it though, and feel like its overly complex, but here's the criteria that I used. I also wanted to avoid others (non-administrators) from having to "escalate their security context", and was hoping to use DEFAULT PRIVILEGES to do this. Unfortunately, that didn't work for me, which I believe is a result of using a hosted solution, and not having a true SUPERUSER role.
Overview
3 default roles
db_reader, read-only access to user-defined databases
db_writer, read-write access to user-defined databases
db_admin, full database access to user-defined databases
Each role inherits the privileges of its “parent”
db_writer inherits all privileges of db_reader
db_admin inherits all privileges of db_writer
Role-based Privileges
Reader role (db_reader)
CONNECT on all user-defined databases
USAGE on all user-defined schemas
SELECT on all user-defined tables, views, and sequences
Writer role (db_writer)
all privileges associated with db_reader
INSERT, UPDATE, DELETE on all user-defined tables and sequences
Admin role (db_admin)
all privileges associated with db_writer
CREATE on all user-defined databases
TRUNCATE on all user-defined tables
Two types of roles
Group Role (users and permissions)
User Role (generally personal or application names)
Privileges are assigned to group roles via GRANT and REVOKE.
User roles inherit privileges from associated group roles and have the LOGIN privilege.
In my scenario the user is the owner of the database and whatever is / will be in it should be fully accessible to him / her. But I don't want the user to have any access to anything outside of his/her own database.
As I mentioned the structure of the database would change over the time and I prefer not to reset the permissions for each table / schema / function added.
How can I grant such a permission in PostgreSQL?
I think your best answer is actually that, by default, the owner can always grant/revoke privileges on any database object. So if all tables are owned by the database owner, then by default he or she will have all access to these but others may not. The owner can also assign permissions as well. So make sure all tables are created by that user and there is no problem. For other tables you can change the owner using ALTER TABLE later.
At any rate, reading between the lines, that looks like what you are asking about. ALTER DEFAULT PRIVILEGES also works but the role you are trying to grant to could then be locked out by the owner of a given table.
I have a Postgresql database for a web application. The database is owned by a particular user on the system, let's say foouser. As the owner, this user has full permissions on the database.
The server also has another user, let's say webappuser, which is the user under which the application server runs. Instead of specifying a username and password in the web application's config file, I want to use "peer" authentication. I have gotten the authentication to work properly, but I ran into the following issue.
When I created the webappuser role in Postgresql, I granted it LOGIN permission as well as GRANT ALL ON DATABASE foo TO webappuser; and within the database GRANT ALL ON SCHEMA public TO webappuser;.
The issue that I am having is with the table permissions. Unlike MySQL which allows access by default to all tables if you have access to the database (a reasonable assumption in my opinion), Postgresql denies access to all of the tables even though permission has been given on the schema and the database. In order to get around this, I have to explicitly grant permissions on all new tables, views, procedures, etc. that I create using GRANT ALL ON TABLE table_name TO webappuser; (and similarly for views, etc.).
It ends up that any time I run a database migration, I have to add the permissions to the database for the new tables that were created. The problem is that I can't add this permission information to the migrations themselves because developer machines don't have that additional user. In any case, that really looks like the wrong way of doing things.
How can I allow access to the database tables from this additional user without needing manual intervention every time a table, view, procedure, etc. is created?
BONUS POINTS: Is there a way to restrict the user's permission to only CRUD operations instead of full permissions and still do the whole thing automatically?
Without experience with the specifics of Laravel migrations: When you do migrations on the same server there should be no problem, so long as the permissions are also migrated, because the webappuser is available cluster-wide.
When migrating to a different server you need to create the user on that new server and set the permissions for all migrated objects. You basically have two ways to do that.
The first is to set default privileges on the tables in the schema before you migrate or GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA sch_name TO webappuser after the migration. Default privileges are set with:
ALTER DEFAULT PRIVILEGES IN SCHEMA sch_name
GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO webappuser;
Both commands are fully SQL-standard compliant so you should have no problems across compliant architectures.
Keep in mind that any other tables created in the same schema will also have privileges set for webappuser. Setting privileges this way for an "untrusted" user (the person using the web application) is not recommended in a production environment because of potential privilege leaks; in a development environment it may be acceptable.
The second - which I would favour personally - is to write a stored procedure that sets the appropriate permissions. Do the migration, run the stored procedure once and you should be up-and-running. This gives you more control over the permission granting. The procedure could be something like:
CREATE FUNCTION grant_webapp_privileges() RETURNS void AS $$
-- Create the webappuser, if necessary
CREATE ROLE webappuser LOGIN;
-- Grant privileges on all required objects
GRANT SELECT, INSERT, UPDATE, DELETE ON TABLE table1 TO webappuser;
...
$$ LANGUAGE SQL;
On the master database you simply need to keep the stored procedure up-to-date when you create or drop new relations. If Laravel supports insertion of code blocks not in the schema you are migrating, you can make the above procedure an anonymous code block that gets executed after the migration.
(As an aside, I NEVER give webappuser-like roles CRUD access. Instead I always provide access through views that hide some of the underlying data model specifics, such as a person having an address, contact_information and other details; the view serves it all up in one big row. That way you can easily change the underlying relations and update the view, rather than having to tweak your web application. Same principle really as OOP and easier to manage privileges.)
I want to create a postgres user that can access only one database on the postgres server at all.
Currently my flow is:
create database database1;
create user user1 with password 'pass';
grant all privileges on database database1 to user1;
but user1 can still see a list of dbs, users, tables etc. Is there a way to prevent that user from seeing that info? The user needs to be able to write to and read from that db.
Thanks a lot.
Each user can see other databases and roles listed, but should not be able to see tables in other databases, ever.
If you revoke CONNECT privilege on all databases except the allotted one, the user will not be able to access the contents of other databases.
Roles and database names are global, and not readily blockable. You can try Frank Heikens suggestion of selective revocations on the system tables, but you take risks to do that. PostgreSQL developers on the usenet mailing lists have discouraged tampering with access to the system catalogs.
Psql, among other tools, assumes they will be available and functions poorly without them.
Why is knowing the names of other databases and roles so bad?
REVOKE the SELECT permissions on the information_schema and some sections in the system catalog.
By default any objects you create are created in the public schema. Also, any users that you create have CREATE and USAGE privileges on the public schema. You should revoke CREATE and USAGE to the public schema for this user, or you should change the default access level. You'll also need to move the database to which this user has access into the user's schema, or a schema accessible to the user. See DDL Schemas in the Postgres manual.