Re: Updates of SE-PostgreSQL 8.4devel patches (r1268)

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org, Zeugswetter Andreas OSB sIT <Andreas(dot)Zeugswetter(at)s-itsolutions(dot)at>, KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>, KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Updates of SE-PostgreSQL 8.4devel patches (r1268)
Date: 2008-12-11 16:53:42
Message-ID: 200812111653.mBBGrgu23004@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut wrote:
> On Thursday 11 December 2008 17:04:05 Bruce Momjian wrote:
> > The idea is that the security columns will hold an OID and the OID will
> > point to a row in a table that contains the security rights/ACL for the
> > column, with multiple rows using the same rights OID.
>
> That sounds somewhat scary for a number of reasons:
>
> 1. Running out of OIDs, the main reason why we got rid of OIDs in user tables
> by default. This would essentially put them back.
>
> 2. You are implying some kind of ACL unification algorithm, to combine
> identical ACLs under one ID. How will that work, and how will it be managed?
>
> 3. The performance impact of having to look somewhere else for every row
> fetched. If you propose a cache, note that this cache has potentially one
> possible entry for every row in the database. That would need significant
> thought and tuning.
>
> 4. Size scalability of the whole thing. When using IDs as references is being
> proposed, somewhere in there is a total size limitation for a row-security
> enabled database.
>
> Even if you manage to solve #2, is this cleanup feasible to run on a database
> that has run into the limits of #4?
>
> I suppose that SELinux in the kernel addresses these issues somehow (e.g.
> caching), but what would the SQL-only solution do?

Agreed.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2008-12-11 17:11:06 Re: posix_fadvise v22
Previous Message Alvaro Herrera 2008-12-11 16:39:29 Re: Refactoring SearchSysCache + HeapTupleIsValid