2đź‘Ť
-
Yes it is a good (although rare for web applications) practice for servers to not have write or read access to files it does not have to.
-
Yes it means that any process, which is run by postgres OS user, can access any database as postgres database user. And it is enforced by ident, but not insecure and unreliable network ident but local, secure and reliable SO_PEERCRED.
I’d also recommend that services connect not by password but by local ident — if attacker gains somehow read privilege to settings file (for example from backups, insecure transfer etc.) with saved password then it can do anything to database. With ident it has to be able to run code as particular user, which is much harder.
-
Everything is a security risk. Security is an art of managing this risk — managing balance between secure and convenient. If you can configure your server that it does not need access to this files and it would not be overly impractical (for example needs manual intervention on reboot) then go for it. Maybe this “ident” authentication would be better.
1đź‘Ť
- It’s generally a good practice to be as paranoid about permissions as possible–so yes. 🙂
- Yes, yes and yes.
- Everything that’s allowed is a “security risk” but sometimes it just doesn’t work otherwise. uWSGI is your application server, how is he supposed to run your code, if it can’t read it?
- [Django]-Django charfield with default empty string is required in admin
- [Django]-Docker exec sees changes in local files