From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Updates of SE-PostgreSQL 8.4devel patches (r1197) |
Date: | 2008-11-07 21:06:40 |
Message-ID: | 1226092000.27904.154.camel@ebony.2ndQuadrant |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, 2008-11-07 at 13:19 -0500, Bruce Momjian wrote:
> The security context on each row could be an optional column present
> > only if HEAP_HASSECURITYCONTEXT is set (0x0010 see htup.h), just
> like
> > OIDs. Use a specific datatype rather than TEXT. That datatype could
> be
> > an identifier to pg_security. Security people have big databases
> too, so
> > we need to compress the security context more and take out parse
> time of
> > string handling. Don't think we should use Oids, they're too big.
> Might
> > be easier to use a 2byte field and restrict access to 32,000
> contexts,
> > which is easily enough. TEXT also makes me nervous, just in case
> there
> > is some collation/encoding weirdness that allows contexts to be
> > subverted. Fixed integers are hard to compromise in that respect.
>
> I think the security mechanism is more complex than just assigning a
> single security identifier, but perhaps not; I am unsure.
Maybe. We already handle such complexity for comboids and multixacts, so
I suggest we do the same thing here.
Any system with more than 32,000 security contexts is going to be
unmanageable and probably therefore insecure...
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2008-11-07 21:11:05 | Re: Updates of SE-PostgreSQL 8.4devel patches (r1197) |
Previous Message | Greg Sabino Mullane | 2008-11-07 21:03:38 | Updated backslash consistency patch |