Tom Lane wrote: > "Robert Haas" <[EMAIL PROTECTED]> writes: >>> That's the wrong question. The question here is: does it make sense to >>> have per-row permissions implemented on top of an abstraction layer >>> whose sole current implementation is SE-Linux? > >> Er, Bruce was asking about per-column, not per-row. > >> There's a patch listed on CommitFest:2008-09 to introduce per-column >> permissions, but it's apparently still WIP. How much does that >> overlap/conflict with these patches? > > Yeah, Stephen Frost is working on that and still has a ways to go. > I think he might get it done in time for 8.4 (ie, in time for the > November commitfest) but it's far from certain. > > Per-column permissions are part of the SQL standard, and so I think > we have to implement that without depending on any OS-specific > infrastructure.
Yes, I agree this position. The OS-specific infrastructure works orthogonally with native SQL standard access controls, as DAC/MAC works orthogonally on operating system. > So on that end I agree with Bruce's position that > we should do the SQL version first and then think about extensions > for SELinux. A proposal of fine-grained security without OS is here: http://archives.postgresql.org/pgsql-hackers/2008-09/msg01528.php I'll pay my effort to submit a series of patches due to end of the Oct. > Per-row is not in the spec and so we can design that as we please. > But as I mentioned a moment ago, I don't see how it can possibly > play nice with foreign keys ... As I noted in above message, it handles PK/FK constraints as follows: - When a user tries to insert/update a tuple with duplicate PK, it is failed independent from its visibility. - When a user tries to insert/update a tuple with FK, the refered PK have to be visible. - When a user tries to update/delete a tuple with PK which is refered by invisible FK, it is failed independent from its visibility. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <[EMAIL PROTECTED]> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
