Re: [PATCH] Largeobject access controls - Mailing list pgsql-hackers

Robert Haas wrote:
> 2009/9/3 KaiGai Kohei <kaigai@ak.jp.nec.com>:
>> KaiGai Kohei wrote:
>>> Alvaro Herrera wrote:
>>>> Tom Lane wrote:
>>>>> KaiGai Kohei <kaigai@kaigai.gr.jp> writes:
>>>>>> BTW, currently, the default ACL of largeobject allows anything for owner
>>>>>> and nothing for world. Do you have any comment for the default behavior?
>>>>> Mph.  I think the backlash will be too great.  You have to leave the
>>>>> default behavior the same as it is now, ie, world access.
>>>> BTW as a default it is pretty bad.  Should we have a GUC var to set the
>>>> default LO permissions?
>>> It seems to me a reasonable idea in direction.
>>> However, it might be better to add a GUC variable to turn on/off LO
>>> permission feature, not only default permissions.
>>> It allows us to control whether the privilege mechanism should perform
>>> in backward compatible, or not.
>> Now we have two options:
>>
>> 1. A GUC variable to set the default largeobject permissions.
>>
>>  SET largeobject_default_acl = [ ro | rw | none ]
>>    - ro   : read-only
>>    - rw   : read-writable
>>    - none : nothing
>>
>>  It can control the default acl which is applied when NULL is set on
>>  the pg_largeobject_meta.lomacl. However, lo_unlink() checks ownership
>>  on the largeobject, so it is not enough compatible with v8.4.x or prior.
>>
>> 2. A GUC veriable to turn on/off largeobject permissions.
>>
>>  SET largeobject_compat_dac = [ on | off ]
>>
>>  When the variable is turned on, largeobject dac permission check is
>>  not applied as the v8.4.x or prior version did. So, the variable is
>>  named "compat" which means compatible behavior.
>>  It also does not check ownership on lo_unlink().
>>
>> My preference is the second approach.
>>
>> What's your opinion?
> 
> I prefer the first.  There's little harm in letting users set the
> default permissions for themselves, but a GUC that controls
> system-wide behavior will have to be something only superusers can
> money with, and that seems like it will reduce usability.

I don't intend to allow session users to set up their default acl.
Both operation should be always system-wide.

If a normal user can change the default acl, it is also equivalent
he can grant all permissions to public on all the largeobject with
its acl being NULL.
Note that PostgreSQL does not set up a certain ACLs on its creation
time, so NULL is assigned. The default ACL means an alternarive set
of permissions, when it is NULL.


> Why couldn't lo_unlink() just check write privilege?

Because it is inconsistent behavior.
PostgreSQL checks its ownership on dropping a certain database objects,
such as tabls, procedures and so on.
It seems to me quite strange, if only largeobject checks writer permission
to drop itself.

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