Thanks a lot, very helpful video with crisp and to the point information. One query i had, would be helpful if you can advise. Isn't a shared memory where multiple database backend processes handling respective client connections and using this shared memory to storedl client database data a security risk ? Considering that in case of some mishandling of shared memory, one compromised backend process can read or modify data of another database handled by another backend process ?
If you're talking about a database object that is created by the CREATE DATABASE command, then the access is controlled by the roles created for applications. For instance, if database_app1 and all its data can be accessed only by app1, then there needs to be a role that has required level of access to the database. All other roles and other apps will be prohibited from connecting and accessing database_app1. See these docs for details (if it's new to you): www.postgresql.org/docs/current/user-manag.html Shared memory acts transparently for the applications and the application layer has no access to it, it's just internal Postgres server's component. If the role used by app1 for database_app1 access is hacked (for instance, bad actors now know credentials of the role), then the bad actors can access database_app1 only and steal the data. But those actors won't have access to other database...unless the hacked role had superuser privileges. Overall, don't use the default "postgres" role at the application layer because the role has superuser access to the database server. Create application specific roles with fine-grained permissions for every app and you'll have a piece of mind in production.
I really like how you’re combining both theoretical concepts and practical concepts. Looking forward to more videos like this.
Thanks a lot for your feedback! It matters a lot to me and encourages to keep working on the content 👍
Another simple and awesome video. Great work pal! I can't wait for the next episode 🍿
Thanks a ton, my friend! I’ll do my best to get the good stuff coming 👍
Really informative video, keep up the good work✴
Thanks, glad you found it helpful!
Keep it up man! nice video
I’ll do my best to produce more videos in the future. As of now, I have to focus on a book about Postgres ;)
Thanks a lot, very helpful video with crisp and to the point information. One query i had, would be helpful if you can advise.
Isn't a shared memory where multiple database backend processes handling respective client connections and using this shared memory to storedl client database data a security risk ? Considering that in case of some mishandling of shared memory, one compromised backend process can read or modify data of another database handled by another backend process ?
If you're talking about a database object that is created by the CREATE DATABASE command, then the access is controlled by the roles created for applications. For instance, if database_app1 and all its data can be accessed only by app1, then there needs to be a role that has required level of access to the database. All other roles and other apps will be prohibited from connecting and accessing database_app1. See these docs for details (if it's new to you): www.postgresql.org/docs/current/user-manag.html
Shared memory acts transparently for the applications and the application layer has no access to it, it's just internal Postgres server's component. If the role used by app1 for database_app1 access is hacked (for instance, bad actors now know credentials of the role), then the bad actors can access database_app1 only and steal the data. But those actors won't have access to other database...unless the hacked role had superuser privileges.
Overall, don't use the default "postgres" role at the application layer because the role has superuser access to the database server. Create application specific roles with fine-grained permissions for every app and you'll have a piece of mind in production.
:D