From: | Craig Ringer <ringerc(at)ringerc(dot)id(dot)au> |
---|---|
To: | Rainer Leo <leo(at)workfile(dot)de> |
Cc: | pgsql-admin(at)postgresql(dot)org |
Subject: | Re: Best procedure for restricted access |
Date: | 2011-09-12 15:26:58 |
Message-ID: | 4E6E24C2.5050901@ringerc.id.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
On 12/09/2011 9:16 PM, Rainer Leo wrote:
> Hello,
>
> I have been asked to configure a database role
> to be used for ODBC access.
>
> So far I have done this:
>
> CREATE ROLE odbc_user LOGIN
> ENCRYPTED PASSWORD 'bar'
> NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE;
>
> REVOKE ALL ON DATABASE foo FROM odbc_user;
> REVOKE CREATE ON SCHEMA public FROM public;
> GRANT SELECT ON v_sales TO odbc_user;
>
> When I try:
>
> foo-> SELECT * FROM customers;
> access is denied as expected
>
> foo->\d baz
> I see table definitions.
You'd have to mess with permissions on the pg_catalog tables and the
INFORMATION_SCHEMA views. This may have unexpected side-effects or cause
some clients that expect to be able to use those schema to get metadata
to cease functioning correctly.
I don't think denying access to table definitions is part of the
security model's goals at the moment; it's about limiting access to
_data_ not DDL or definitions. You'll note that function sources are
also available via pg_catalog, though it seems to be reasonably safe
(from what I hear, having not tested it) to change permissions to deny
access to those.
--
Craig Ringer
From | Date | Subject | |
---|---|---|---|
Next Message | Ben Ciceron | 2011-09-12 17:04:07 | monitoring replicatgion : lag calculation |
Previous Message | Guillaume Lelarge | 2011-09-12 15:08:30 | Re: pgAdmin 1.14 backup globals calls pg_dump.exe not pg_dumpall.exe (included pgSQLl 9.1 Windows 32 binary |