Re: Updates of SE-PostgreSQL 8.4devel patches (r1268)
От | Aidan Van Dyk |
---|---|
Тема | Re: Updates of SE-PostgreSQL 8.4devel patches (r1268) |
Дата | |
Msg-id | 20081211195933.GC26596@yugib.highrise.ca обсуждение исходный текст |
Ответ на | Re: Updates of SE-PostgreSQL 8.4devel patches (r1268) (Gregory Stark <stark@enterprisedb.com>) |
Ответы |
Re: Updates of SE-PostgreSQL 8.4devel patches (r1268)
|
Список | pgsql-hackers |
* Gregory Stark <stark@enterprisedb.com> [081211 14:47]: > Peter Eisentraut <peter_e@gmx.net> writes: > > > On Thursday 11 December 2008 18:32:50 Tom Lane wrote: > >> > How can we stick all of these in the same column at the same time? > >> > >> Why would we want to? > > > > Because we want to use SQL-based row access control and SELinux-based row > > access control at the same time. Isn't this exactly one of the objections > > upthread? Both must be available at the same time. > > Well I don't think anyone would actually want them *at the same time*. > Combining multiple security models would mean you aren't actually following > any security model. Actually, I think people (or rather, systems) will. No "application" is going to want to use SE-linux, but "OS controllers" are... Just like now, the actual people/apps/etc rely on plain unix permissions, yet the distro still provides an SElinux policy that is "more restrictive yet"... Simlarly, SElinux is going to be used *on top* of any application that's out there, to try and enfoce the "no data coming in from a secure input" leaves through a "less secure output", irrespective of what app level security (and in this case, app-level being the SQL/SCHEMA/row-level) does itself... So, if row-level access comes to PG in any sql form, apps and others will use it (if only a few of them)... And se-linux on top of that will be used to try and enforce that the app hasn't made a mistake... a. -- Aidan Van Dyk Create like a god, aidan@highrise.ca command like a king, http://www.highrise.ca/ work like a slave.
В списке pgsql-hackers по дате отправления: