2. If somebody manages to hijack your connection, you have much worse
problems than whether they can read your system catalogs. They can at
least copy, and probably modify, your user data.
If I have restricted those permissions (i.e. access to specific schemas
only, allowing specific operation
Mr Dash Four writes:
>> if you broke the permissions on the pg_catalog so badly that the SQL
>> planner can't look up the data types of the fields of your own tables,
>> well, thats just wrong.
> What's the alternative?
Perhaps more careful thought about your threat model?
> I am not willing
'user: ' *is* text by default.I didn't notice you displaying
your table definitions, but assuming u_name is TExT or VARCHAR(...)
it should have worked without any explicit casts
u_name is a custom-defined type, consisting of user name (text/varchar),
a number (longint), host name (text
On 10/01/12 1:20 AM, Mr Dash Four wrote:
FWIW, it's probably the "'user: ' || u_name" expressions that result
in this specific failure.
I found what is the cause of this - I had to add an explicit cast on
all text expressions, like "user: "::text as well as u_name::text.
That way the problem go
You caused it yourself, then. Don't do that. (Or if you must,
it's your own responsibility to fix things when they break. But
preventing read access to pg_catalog seems pretty crippling.)
I don't want arbitrary program to have access to the system catalogue
and read willy-nilly, thanks.
Mr Dash Four writes:
> In my database I have restricted access to a particular user
> (non-superuser), which is used when a cron job passes a series of sql
> script files for execution via psql. During one such statement (below) I
> get the following set of error:
> ERROR: permission denied f
In my database I have restricted access to a particular user
(non-superuser), which is used when a cron job passes a series of sql
script files for execution via psql. During one such statement (below) I
get the following set of error:
ERROR: permission denied for schema pg_catalog
CONTEXT:
