Re: security checks for largeobjects?

Поиск
Список
Период
Сортировка
От KaiGai Kohei
Тема Re: security checks for largeobjects?
Дата
Msg-id 4A3F0FDA.8080202@ak.jp.nec.com
обсуждение исходный текст
Ответ на security checks for largeobjects?  (KaiGai Kohei <kaigai@ak.jp.nec.com>)
Ответы Re: security checks for largeobjects?  (David Fetter <david@fetter.org>)
Re: security checks for largeobjects?  (KaiGai Kohei <kaigai@ak.jp.nec.com>)
Список pgsql-hackers
KaiGai Kohei wrote:
> The todo list says, as follows:
> * Binary Data
>   o Add security checks for large objects
> 
> http://wiki.postgresql.org/wiki/Todo#Binary_Data
> 
> Is anyone working on? or interested in?

OK, it seems to me nobody is working on the todo item.
I'll also submit this feature on the v8.5 development cycle.

At first, I would have a discussion about its interfaces and
functionalities. Here are a few issues.

* What permissions should be checked?
It is quite natural to check 'read' and 'write' permission for
largeobjects. In addition, we may need to consider how 'create'
and 'unlink' permission should be handled.
When we create a database objects under the certain schema,
it checks ACL_CREATE privilege on the parent schema object.
But, now largeobjects are not corresponding to any certain
schemas.
When we drop a database objects, it checks ownership of the
target objects. But, now largeobjects does not have its owner
identifier within pg_largeobject.

My preference is to add a namespace and a owner id for each
largeobjects and checks create permissions for the schema
object, and unlink permission based on its ownership.

* What interface is preferable?
We have two options here.
The one is an enhancement of current GRANT/REVOKE statement,
such as: GRANT READ,WRITE ON LARGE OBJECT 1234 TO kaigai;

The other option is a few new largeobject functions to set up
permissions on largeobjects, such as: SELECT lo_grant(1234, 'kaigai', 'read,write');

My preference is the later approach because the first one consumes
two new permission bits, although here is no fundamental differences
to SELECT and UPDATE.

Thanks, any comments please.
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "rct682"
Дата:
Сообщение: enquery for timezone GMT
Следующее
От: tomas@tuxteam.de
Дата:
Сообщение: Re: Suppressing occasional failures in copy2 regression test