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
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 |