| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
| Cc: | Magnus Hagander <mha(at)sollentuna(dot)net>, Andreas Pflug <pgadmin(at)pse-consulting(dot)de>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Dave Page <dpage(at)vale-housing(dot)co(dot)uk>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: For review: Server instrumentation patch |
| Date: | 2005-07-25 14:51:35 |
| Message-ID: | 27690.1122303095@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> I still think, security considerations aside, that an API for config
> settings would be a much better piece of design than providing file
> system access functions.
I agree with that. Given what we currently have, though, remote config
and remote log examination do require filesystem access. But IMHO
there's no very good reason why admin actions requiring filesystem
access shouldn't be programmed in an untrusted PL, rather than through
separate file-access functions. Andreas argued that he didn't want to
make pgAdmin functionality dependent on the availability of an untrusted
PL, but I think that argument is bogus. If the admin doesn't want to
install an untrusted PL for pgAdmin to use, why in the world would he
be happy with equivalent functionality being installed in such a way
that he can't get rid of it?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Magnus Hagander | 2005-07-25 14:54:54 | Re: For review: Server instrumentation patch |
| Previous Message | Magnus Hagander | 2005-07-25 14:47:30 | Re: For review: Server instrumentation patch |