Re: [PATCH] Largeobject access controls

Jaime Casanova wrote:
> 2009/9/23 KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>:
>> Jaime,
>>
>> KaiGai Kohei wrote:
>> | > ALTER LARGE OBJECT is working, but now that we can change the owner of
>> | > a LO we should be able to see who the actual owner is... i mean we
>> | > should add an owner column in \dl for psql (maybe \dl+) and maybe an
>> | > lo_owner() function.
>> |
>> | I would like to buy your idea at the revised patch.
>>
>> Now we don't have xxx_owner() function for other database objects,
>> such as tables, procedures and so on.
>
> good point, but we have has_xxxxxx_privileges() family of functions
> but i think we can add them later if needed...

Yes, the has_xxxxxx_privileges() family should be added later or soon.
Anyway, what I wanted to say is we have no special functions to show
owner of the database objects.

>> Jaime Casanova wrote:
>>>> Do you think the "largeobject_compat_acl" is a meaningful name, instead?
>>> maybe something like "largeobject_security_controls"?
>> It is important to contain a term of "compat" which means compatible,
>> because this GUC does not disables all the security checks.
>> The v8.4.x checks superuser privilege on using lo_import()/lo_export().
>> It is also checked in this patch, even if the GUC is turned on.
>>
>> The purpose of the GUC is to provide compatible behavior, not to provide
>> a stuff to turn on/off all the security features in largeobjects.
>>
>
> that's why the section in the postgresql.conf is called
> "VERSION/PLATFORM COMPATIBILITY" and the subsection "Previous
> PostgreSQL Versions" we have other compatibilty GUC and no ones of
> those has the term "compat" in it...

Indeed, I put the "largeobject_compat_acl" in the compatibility section,
but no other GUCs have "compat" prefix/suffix. It seems to me fair enough.

>> So, I still prefer the "largeobject_compat_acl".
>
> maybe "enhanced_largeobjects_checks" or "enhanced_lo_checks"
> or make the GUC an enum and name it "largeobject_control_checks" with
> posible values "basic" and "enhanced"

But, isn't the "enhanced" tumid expression? It just applies native database
privilege mechanism on largeobjects, as if it does on other objects.

An other alternative is "largeobject_check_acl". What's your feeling?

Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>