2009/9/3 KaiGai Kohei <kai...@ak.jp.nec.com>: > KaiGai Kohei wrote: >> Alvaro Herrera wrote: >>> Tom Lane wrote: >>>> KaiGai Kohei <kai...@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. Why couldn't lo_unlink() just check write privilege? ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
