Re: Updates of SE-PostgreSQL 8.4devel patches
От | KaiGai Kohei |
---|---|
Тема | Re: Updates of SE-PostgreSQL 8.4devel patches |
Дата | |
Msg-id | 48EED58C.3080901@ak.jp.nec.com обсуждение исходный текст |
Ответ на | Re: Updates of SE-PostgreSQL 8.4devel patches (Andrew Sullivan <ajs@commandprompt.com>) |
Ответы |
Re: Updates of SE-PostgreSQL 8.4devel patches
(Andrew Sullivan <ajs@commandprompt.com>)
|
Список | pgsql-hackers |
Andrew Sullivan wrote: > On Wed, Oct 08, 2008 at 11:36:19AM +0900, KaiGai Kohei wrote: >> Yes, unfortunatelly. >> No one replied to my proposed design: >> http://marc.info/?l=pgsql-hackers&m=122222470930544&w=2 > > FWIW, I didn't know what to say about that proposal because I still > don't know what problems any of this is trying to solve. Please note that the above row-level permission works independently and exclusively with SE-PostgreSQL. It simply applies DAC policy inside RDBMS with per-tuple granuality, and will help fine-graned access control independent from MAC polisy or operating system. > 1. Single-policy access control for all objects available in a > system. I'm guessing that this is the point of SE-PostgreSQL. It > also appears to me that the SE-Linux approach may not have completely > defined how these things work in a database context, Its specification got a bit legacy now, so I have a plan to revise it later, as Peter montioned before. Indeed, SELinux does not define detailed behavior in database context and it depends on architects. For example, we can implement column level access control with replacing violated columns by NULL. SE-PostgreSQL does not adopt such approach, but it was an option. Perhaps, someone adopt this approach when he tries to make SE-MySQL. :-) > 2. Granular row-level access control based on database-level ACLs. I > have formed the impression that there is some support of this sort > needed anyway to implement (1), but maybe not. I guess this is the > proposal you mention. As I mentioned at first, the row-level ACL does not intend to apply a single unified security policy. It is an extention of existing database-level ACL, and works independently from the philosophy of SE-PostgreSQL. > What is the goal here? Simply administrator-defined controls on> data access inside the database? Yes, it is a simple extention of existing ACL system to per-tuple granuality, not something more than. > 3. Column-level access controls. This is ruled out of the current > discussion in the proposal mentioned above. Surely you need > column-level access controls to make (1) work, though? If not, then > I'm even more confused than I thought. Now Stephen Frost is working for Column-level permission based on the SQL standard, as a core facility of PostgreSQL. The row-level permission is an optional facility, because we have no standard to be refered. Please note that several major commercial RDBMS also have its optional facility to provide row-level permission, like Oracle Label Security, Oracle Virtual Private Database and DB2 LBAC. > 4. Metadata-level access controls. None of the proposals so far seem > to provide a complete set of access controls for the system details -- > schemas, databases, &c. Such controls are often requested, so I > wonder about that. We are already have GRANT/REVOKE on databases, schemaes and so on as a core facility. This optional facility does not need to provide it again. > Please understand that I'm not trying to be obstructive, but at the > moment I don't understand what the proposals aim to do. I suggest > that, without some clear statements of what things are trying to do, > and what the intended limitations are, it will always be impossible > for anyone to review the implementation of such a big feature and say > whether it does what it intends to do. In my opinion, the row-level permission facility is a supplemental facility between core PostgreSQL and SE-PostgreSQL. It does not provide a single unified policy and MAC policy, but enables to row-/column- level access controls with existing core facilities. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com>
В списке pgsql-hackers по дате отправления: