I am developing an application which will use a postgreSQL database backend. I want to prevent the user from seeing some of the db objects – stored procs implementation in particular etc.
The “obvious” (but perhaps wrong) way is to GRANT CRUD access to the database to a specific user who will have an encrypted uname/pwd?
Is there another way of doing this?.
Note: My target audience are largely non-programmers, so I don’t need anything that is “unbreakable” (assuming such a thing existed).
PostgreSQL doesn’t really support limiting visibility of procedure source code, user or database lists, etc. The best thing to do is accept that, or implement the procedure in C or PL/Java where it’s somewhat harder to examine at the cost of considerably greater complexity of implementation.
In general, you should not have the database/table owner be the day-to-day operational user of the DB. Create a new user and
GRANTit only the rights that it needs.Most of the system catalogs have default
SELECTrights granted topublicso you really want to limit access you would need to explicitlyREVOKEthat access thenGRANTit back to the database owner and any other users that should have it. You’re likely to want to limit access topg_procif you want to limit access to procedure sources, for example. Such an approach is limited and fragile (root can always gain PostgreSQL superuser access, and from there do anything), but you’ve said that’s probably OK for your purposes.Messing with the system catalogs isn’t really supported and can cause issues with metadata access in JDBC, psql, etc. See this related answer. If you mess with the catalogs and something breaks, you get to keep the pieces.
BTW, if you modify the catalogs, please try to avoid asking questions about databases with hand-modified catalogs here. At minimum specify extremely clearly that you have messed with the system catalogs and exactly what you have done. If possible, reproduce the issue on an unmodified database first.