Re: prevent users from seeing pl/pgsql code in pgadmin

From: "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk>
To: "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>
Cc: <pgadmin-hackers(at)postgresql(dot)org>
Subject: Re: prevent users from seeing pl/pgsql code in pgadmin
Date: 2005-03-16 16:42:56
Message-ID: E7F85A1B5FF8D44C8A1AF6885BC9A0E472BBCB@ratbert.vale-housing.co.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgadmin-hackers

> -----Original Message-----
> From: Merlin Moncure [mailto:merlin(dot)moncure(at)rcsonline(dot)com]
> Sent: 16 March 2005 16:33
> To: Dave Page
> Cc: pgadmin-hackers(at)postgresql(dot)org
> Subject: RE: [pgadmin-hackers] prevent users from seeing
> pl/pgsql code in pgadmin
>
>
> I also tried hacking the search path and putting a pg_proc table into
> the public schema. While this fixed select * from pg_proc
> (but not /df),
> pgAdmin still pulled the function source.

Odd - it didn't here. Every query on pg_proc resulted in a message box
telling me it couldn't select from pg_proc - protecting the source, but
breaking pgAdmin.

> Without checking, I'm
> assuming pgAdmin prefixes the catalog tables in the metadata queries
> (aside: should it?).

Actually, no it doesn't - having just checked my server logs, it doesn't
even set the search path to ensure it's sane. I don't suppose anyone
ever hacked their master database around enough to cause problems there!

> Well, I was hoping for some easy trick but apparently there isn't one.
> I think this is one for -hackers.

It seems to me that it needs a special privilege to grant select on that
*column* to users that didn't create that row or already have
appropriate privs. I suspect that would be quite a hack :-(

Regards, Dave

Browse pgadmin-hackers by date

  From Date Subject
Next Message Merlin Moncure 2005-03-16 16:54:09 Re: prevent users from seeing pl/pgsql code in pgadmin
Previous Message Merlin Moncure 2005-03-16 16:33:00 Re: prevent users from seeing pl/pgsql code in pgadmin