From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: How to get SE-PostgreSQL acceptable |
Date: | 2009-01-29 03:08:57 |
Message-ID: | 20090129030857.GD8123@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* KaiGai Kohei (kaigai(at)ak(dot)jp(dot)nec(dot)com) wrote:
>> I agree that that's no good.
As do I.
> My concern is that superuser is allowed to modify system catalog
> by hand, like:
>
> UPDATE pg_proc SET probin = '/tmp/malicious_library.so'
> WHERE oid = ...;
That UPDATE still goes through permissions checking, and that checking
even includes an explicit check when system catalogs are involved.
Appropriate hooks in that permission checking could prevent this from
ever being allowed.
> It is logically same as ALTER FUNCTION.
Sure, but I think it's straight-forward to make a case for "don't update
the system catalogs when you're running SE-PostgreSQL, use the
appropriate ALTER commands", and then remove the ability to do so when
SE-PostgreSQL is enabled.
>> Can you (or someone) provide a pointer to the archives? I can't
>> immediately see any reason why that problem wouldn't be fixable.
>
> IIRC, 0racle or M$ has a patent to rewrite WHERE clause for security
> purpose, so Tom suggested it should be implemented using a hook
> deployed within executor.
> At least, it also enables code more simple.
It'd probably be Oracle.. I'm not a big fan of that approach anyway
though, although I don't have any particular reason beyond 'it feels
kludgy' at the moment.
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2009-01-29 03:12:10 | Re: pg_upgrade project status |
Previous Message | KaiGai Kohei | 2009-01-29 02:49:06 | Re: How to get SE-PostgreSQL acceptable |