Re: [PATCH] Largeobject access controls

From: Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>
To: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] Largeobject access controls
Date: 2009-09-21 06:32:40
Message-ID: 3073cc9b0909202332kc2fce71padb18fba7754c1d2@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2009/9/6 KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>:
> The attached patch is an update of largeobject access controls.
>

it applies fine (just 3 succeded hunks), compiles and passes
regression tests...

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.

the GRANTs (and REVOKEs) work just fine too...
Another question is what we want that only the LO owner can delete it
(via lo_unlink)?

another one, is it possible for us to have a CREATE LARGE OBJECT statement?
the reason for this is:
1) it is a little ugly to use the OID in ALTER/GRANT/REVOKE
statements, in a create statement we can assign a name to the LO
2) it could be more consistent with other ALTER/GRANT/REVOKE that acts
over objects created with CREATE while large objects are created via
lo_import() which makes obvious that are just records in meta-data
table (hope this is understandable)

> It adds a new guc variable to turn on/off compatible behavior in
> largeobejct access controls.
>
>  largeobject_compat_dac = [on | off] (default: off)
>
> If the variable is turned on, all the new access control features
> on largeobjects are bypassed, as if v8.4.x or prior did.

the GUC works as intended
but i don't like the name, it is not very meaningful for those of us
that doesn't know what DAC or MAC are...
another point, you really have to put the GUC in the postgresql.conf
file if you hope people know about it ;)
it is not documented either

About the code...
- I don't like the name pg_largeobject_meta why not pg_largeobject_acl
(put here any other name you like)? or there was a reason for that
choose?

--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Brendan Jurd 2009-09-21 07:06:06 Re: numeric_to_number() function skipping some digits
Previous Message Jeevan Chalke 2009-09-21 06:10:39 Re: numeric_to_number() function skipping some digits