Re: Updates of SE-PostgreSQL 8.4devel patches
От | Bruce Momjian |
---|---|
Тема | Re: Updates of SE-PostgreSQL 8.4devel patches |
Дата | |
Msg-id | 200809251956.m8PJupI05068@momjian.us обсуждение исходный текст |
Ответ на | Re: Updates of SE-PostgreSQL 8.4devel patches (KaiGai Kohei <kaigai@ak.jp.nec.com>) |
Ответы |
Re: Updates of SE-PostgreSQL 8.4devel patches
Re: Updates of SE-PostgreSQL 8.4devel patches Re: Updates of SE-PostgreSQL 8.4devel patches |
Список | pgsql-hackers |
KaiGai Kohei wrote: > Bruce Momjian wrote: > >> > 2) Do we want row-level permissions at the SQL level? > >> > >> Now I'm working for it and will submit patches due to the end of Oct, > >> if it is really required to make progress reviewing of SE-PostgreSQL > >> on the v8.4 development cycle. > >> However, the scale of its demand is unclear for me. > > > > Yes, which is why I would like the community to answer the question > > before you have to start coding things. I will say that if we do want > > it, the SE-Linux code will be 96% in separate modules and will make it > > much easier to accept. > > OK, I'll stop my hand today, and wait for pgsql-hacker's opinions. Here is how I think SQL-level row permissions would work: We already have an optional OID system column that can be specified during table creation (WITH OIDS). We could have another optional oid column (WITH ROW SECURITY) called security_context which would store the oid of the role that can see the row; if the oid is zero (InvalidOid), anyone can see it. SE-PostgreSQL would default to WITH ROW SECURITY and use the oid to look up strings in pg_security. Is this something we want for non-SE-PostgreSQL builds? SE-PostgreSQL would still be a compile-time option because of all the additional SE-Linux support code. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
В списке pgsql-hackers по дате отправления: