KaiGai Kohei wrote:
> > Particularly interesting was the doc patch,
> > sepostgresql-docs-8.4devel-3-r1043.patch. It explains how SE-PostgreSQL
> > checks the permission level of the client process (getpeercon) and uses
> > that to determine what the user should see.
>
> Yes, this is a significant point which tends to be misunderstood.
> When two processes with individual security context on operating system
> connect to SE-PostgreSQL, they will get individual result, even if they
> logged in as a same database role.
Yes, that was very clear in your documentation.
> > The bulk of the patch is in sepostgresql-sepgsql-8.4devel-3-r1043.patch,
> > which modifies the backend. About 30% of it or 3k lines modify our
> > backend, and the rest are indepdendent support routines in their own C
> > files.
>
> The 3k lines (which is named as PGACE security framework) part was provided
> as separated patches, but I was pointed out it requires reviewers to see
> two files in same time. So, these were integrated into one.
Ah, OK. I think we need to decide:
1) When are we getting column-level permissions that you can
plug into?
2) Do we want row-level permissions at the SQL level?
> > The other conclusion I came to is that the other 11k of patch is really
> > independent SE-Linux interface code and not likely to change in size no
> > matter what we implement at the SQL level.
>
> Yes, the primary purpose of this archtecture is to minimize the impact
> for the core PostgreSQL implementation, when user choose an enhanced
> security mechanism.
Yes, you have certainly done that well.
--
Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
