Re: sudo/access to the postres OS user

It's fairly standard so they can audit who ran psql and when.  It is, however, a pain in the butt.

None.  It's so the SA team can audit your access.  There is no benefit to you.

Your SAs are [I can't say in polite company].  Have them create a dba group and put all the DBAs in it.  Then setup postgres to run as postgres:dba and chown the entire tree postgres:dba and add group write permission where ever it's missing, group read and execute for all directories, and remove all group write permissions.  This will allow you to read any file and enter into and list out any directories, but not change anything.  Then chmod the psql command 700 (or 500) owned by postgres.  This prevents any user from running the utility other than the postgres user which you're assuming when you use sudo.

This gives you the ability, as yourself, to read logs, examine files, etc, but without being able to make any changes to anything (you might compromise with them on the *.conf files, getting them to add write permissions so you can make database configuration changes).  You might also ask them for sudo access to whatever utilities you're using to start/stop the database so you, as a DBA, can shut it down, bounce it, start it, etc.

All of this should have been setup as part of revoking your shell access.  Were there any discussions leading up to this?  All of this should have been covered in those discussions and implemented before your shell access was revoked (which it should not have been, you need shell access to manage a PostgreSQL database).  I can understand removing any ability to control or access the database without sudo (that audit trail), but I can't understand hamstringing your ability to access logs and configuration files.

The goal makes sense.  The implementation makes none.

Chris