| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | Magnus Hagander <mha(at)sollentuna(dot)net> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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 11:44:52 |
| Message-ID: | 42E4D0B4.7020603@dunslane.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Magnus Hagander wrote:
>
>Instead of trying to pick on one feature, how about trying something
>constructive instead? Let's say we add a GUC like "restrict_superuser",
>that disables COPY to local files, untrusted procedural languages (both
>creation and using the ones that already exist), the new access
>functions, the LOAD command etc. Then the admin can chose what to do
>about superuser access levels - the requirement may dependon SELinux for
>example.
>
>
I could go for this.
Creating a setting that disallowed creation/calling of plperlu
functions would be fairly trivial.
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.
cheers
andrew
| From | Date | Subject | |
|---|---|---|---|
| Next Message | ohp | 2005-07-25 12:27:19 | Re: regression failure on latest CVS |
| Previous Message | Magnus Hagander | 2005-07-25 07:43:07 | Re: For review: Server instrumentation patch |