Robert Haas wrote: > On Thu, Dec 10, 2009 at 11:45 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> If you're not prepared to assume that we're going to do row level >> security, it's not apparent why we should be embarking on this course >> at all. And if you do assume that, I strongly believe that my effort >> estimate above is on the optimistic side. > > Row-level security is going to be a very difficult project, no > question about it.
Yes, I also agree it is a reasonable decision to separate row-level from the initial proposition. > However, if we implement a general facility rather > than something SE-Linux specific, I think we will have a killer > feature. I realize it's not for everyone, but for those who need it, > it's kick-ass. > > But we have a while before we get to the point where we can even start > worrying about that pain. Stephen Frost's statements about the way > our access controls are scattered throughout our code are, I think, on > target. And cleaning that up seems to me to have value independently > of SE-PostgreSQL. I'm feeling (right now, anyway) like it would make > sense to pursue further the patch that KaiGai submitted for the last > CF and you rejected. It needed work, but I don't think it was > hopeless, or valueless. Here is a few issues to salvage the access control reworks patch. It tried to provide a set of common entry points both of the default PG security model and SELinux (and upcoming ones). However, the default PG model does not have same origin with label-based mandatory access controls, such as SELinux, from a historical angle. So, this reworks needed many of unobvious changes to the core routines. ("core routines" means code except for enhanced security features.) It tried to provide a set of comprehensive entry points to replace existing PG checks at once. However, the SE-PgSQL/Lite patch covers accesses on only database, schema, tables and columns. Is it necessary to be comprehensive from the beginning? It might be too aggressive changes at once. Frankly, I hesitate to salvage the patch once rejected, as is. If we implement a set of security hooks, It seems to me the following approach is reasonable: * It does not touch the existing PG default checks. The purpose of security hooks are to host "enhanced" security features. * It does not deploy hooks on which no security provider is now proposed. It is important to reduce unnecessary changeset. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kai...@ak.jp.nec.com> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers