| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
| Cc: | Bryn Llewellyn <bryn(at)yugabyte(dot)com>, Neeraj M R <neerajmr12219(at)gmail(dot)com>, pgsql-general list <pgsql-general(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Restricting user to see schema structure |
| Date: | 2022-05-12 19:14:20 |
| Message-ID: | CAKFQuwYmBFKrfTstgQPSRG-gAt-2Ne=vdQOfmEUL2Sy8x5S6Cg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Thu, May 12, 2022 at 11:44 AM Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
wrote:
> On 5/12/22 11:29, Bryn Llewellyn wrote:
>
> > I've prototyped this scheme. It seems to work as designed. A client that
> connects with psql (or any other tool) can list the API functions and
> whatever \df and \sf show. (notice that \d will reveal nothing.)But doing
> this reveals only the names of the functions that are called (which will be
> identical to the jacket names—so no risk here) and the name(s) of the
> schema(s) where they live (so a minor theoretical risk here).
> >
> > Full disclosure: I've never done this in anger.
>
> Try select * from pg_class or select * from pg_attribute or any of the
> other system catalogs.
>
>
Which is exactly what most GUI applications that provide object browsing
and viewing are going to use.
David J.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bryn Llewellyn | 2022-05-13 02:35:56 | Re: Restricting user to see schema structure |
| Previous Message | Adrian Klaver | 2022-05-12 18:44:27 | Re: Restricting user to see schema structure |