| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Stephen Frost <sfrost(at)snowman(dot)net> |
| Cc: | Magnus Hagander <mha(at)sollentuna(dot)net>, Andrew Dunstan <andrew(at)dunslane(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 15:15:10 |
| Message-ID: | 27870.1122304510@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Stephen Frost <sfrost(at)snowman(dot)net> writes:
> If you want to secure your system against a superuser()-level intrusion
> then you need to secure the unix account, or disable creation of
> C-language and other untrusted languages (at least).
Very likely --- which is why Magnus' idea of an explicit switch to
prevent superuser filesystem access seems attractive to me. It'd
have to turn off LOAD and creation of new C functions as well as COPY
and the other stuff we discussed.
However, once again, the availability of security hole A does not
justify creating security hole B. For example, even with creation
of new C functions disabled, a superuser attacker might be able to use a
file-write function to overwrite an existing .so and thereby subvert an
existing C-function definition to do something bad.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2005-07-25 15:16:42 | Re: regression failure on stats test |
| Previous Message | Magnus Hagander | 2005-07-25 14:54:54 | Re: For review: Server instrumentation patch |