Hi there,
in PG 14, you've removed explicit 'superuser()' checks in file-access
functions (like pg_ls_dir, pg_read_file, etc.) and moved to an ACL based
approach to restrict access to these functions. In turn, you've also
removed EXECUTE permission from role "public", leaving these functions
accessible by superusers only.
See also:
https://github.com/postgres/postgres/commit/e79350fef2917522571add750e3e21af293b50fe
The docs state (up to PG 16), that, in order to access files *outside*
the cluster directory and the "log_directory", a user must be a
superuser OR must be granted the role "pg_read_server_files".
https://www.postgresql.org/docs/16/functions-admin.html#FUNCTIONS-ADMIN-GENFILE
> Only files within the database cluster directory and the log_directory can be accessed, unless the user is a
superuseror is granted the role pg_read_server_files.
Actually, it seems that it does not matter what file I'm trying to
access as a non-superuser. There's no distinction between cluster or log
directory and any other directory. Only the function's ACL seems to
govern who can execute the function.
After explicitly granting EXECUTE permission for such a function to a
non-superuser, it can access any file the server backend has read-access to.
Maybe the documentation is partially outdated (mixing old superuser()
and new ACL-based behavior)? In any case, it could/should be more clear
in this respect.
Also, as you can see in the above commit, while removing EXECUTE perms
from role "public", you grant EXECUTE perms for some of them to role
"pg_monitor". You still do this in PG 16 for even more functions (now in
new file system_functions.sql ->
https://github.com/postgres/postgres/blob/master/src/backend/catalog/system_functions.sql).
Why don't you grant EXECUTE perms to predefined role
"pg_read_server_files"? That would make this role not as useless as it
currently seems to be (for my mind, at least).
Is there something that I'm overlooking?
Regards, Carsten