Re: Updates of SE-PostgreSQL 8.4devel patches
От | KaiGai Kohei |
---|---|
Тема | Re: Updates of SE-PostgreSQL 8.4devel patches |
Дата | |
Msg-id | 48ED57A5.3010001@ak.jp.nec.com обсуждение исходный текст |
Ответ на | Re: Updates of SE-PostgreSQL 8.4devel patches (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Updates of SE-PostgreSQL 8.4devel patches (r1120)
|
Список | pgsql-hackers |
Bruce Momjian wrote: >> Yes, I have had similar experiences in Linux kernel development for >> several years. >> The amount of time to get consensus is one of the reason why I want >> to move the SQL based row-level security to v8.5 development cycle. > > As I stated before, I think doing an SE-Linux version and then adding a > more generalized solution is doing things in the wrong order because > the generalized solution is going to have to re-do the SE-Linux stuff. > As much as I would like to see SE-Linux support in 8.4, I think we need > general column and row-level permission built with an eye on what > SE-Linux will need, then add SE-Linux security. OK, I decided to pay my efforts to implement row-level permission as soon as possible. Its fundamental idea is same as I posted before. It enables to assign database ACL per tuples, and enables to filter violated tuples from the result set of query. I guess we can see the initial working revision within the next week, if my design was not wrong. >> I guess he intend to share the code for row-level security, thus it >> should be implemented prior to the OS specific feature. But most of >> SE-PostgreSQL code is separated from core implementation and invoked >> via security hooks, so it is unsuitable to share code with other >> facilities. > > You are right based on line counts in the patch, but based on actual > changes to the existing code, SE-Linux changes very much match what > SQL-level permissions would need. In my plan, the row-level permission should be mounted on the PGACE security framework which also mounts SE-PostgreSQL. In this way, we may be able to sat they share common codes. > To summarize, 70% of the SE-Linux patch is in stand-alone C files, which > has little disruption, but 30% are changes to the core backend code, > which will be disruptive, so we would like to have SQL-level permissions > that everyone uses to be that disruption, and have SE-Linux attach to > those capabilities. It is same as my design. A new configure option enables to switch the guest of PGACE security framework, so we will be able to choose one of SE-PostgreSQL, row-level permission and nothing (default). [summary of things which I have to do] (1) To implement row-level permission (*due to the end of Oct*) (2) To improve SE-PostgreSQL, as I have worked before (3) To revise the documentatin/specification to wiki articles for easily publicly accessible. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com>
В списке pgsql-hackers по дате отправления: