Prev: Hot standby, recent changes
Next: YAML
From: Greg Smith on 6 Dec 2009 23:19
I just looked over the latest version of this patch and it seems to
satisfy all the issues suggested by the initial review. This looks like
it's ready for a committer from a quality perspective and I'm going to
mark it as such.

I have a guess what some of the first points of discussion are going to
be though, so might as well raise them here. This patch is 2.8K lines
of code that's in a lot of places: a mix of full new functions, tweaks
to existing ones, docs, regression tests, it's a well structured but
somewhat heavy bit of work. One obvious questions is whether there's
enough demand for access controls on large objects to justify adding the
complexity involved to do so. A second thing I'm concerned about is
what implications this change would have for in-place upgrades. If
there's demand and it's not going to cause upgrade issues, then we just
need to find a committer willing to chew on it. I think those are the
main hurdles left for this patch.

--
Greg Smith 2ndQuadrant Baltimore, MD
PostgreSQL Training, Services and Support
greg(a)2ndQuadrant.com www.2ndQuadrant.com


--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: KaiGai Kohei on 6 Dec 2009 23:42
Greg Smith wrote:
> I just looked over the latest version of this patch and it seems to
> satisfy all the issues suggested by the initial review. This looks like
> it's ready for a committer from a quality perspective and I'm going to
> mark it as such.

Thanks for your efforts.

> I have a guess what some of the first points of discussion are going to
> be though, so might as well raise them here. This patch is 2.8K lines
> of code that's in a lot of places: a mix of full new functions, tweaks
> to existing ones, docs, regression tests, it's a well structured but
> somewhat heavy bit of work. One obvious questions is whether there's
> enough demand for access controls on large objects to justify adding the
> complexity involved to do so.

At least, it is a todo item in the community:
http://wiki.postgresql.org/wiki/Todo#Binary_Data

Apart from SELinux, it is quite natural to apply any access controls on
binary data. If we could not have any valid access controls, users will
not want to store their sensitive information, such as confidential PDF
files, as a large object.

> A second thing I'm concerned about is
> what implications this change would have for in-place upgrades. If
> there's demand and it's not going to cause upgrade issues, then we just
> need to find a committer willing to chew on it. I think those are the
> main hurdles left for this patch.

I guess we need to create an empty entry with a given OID into the
pg_largeobject_metadata for each large objects when we try to upgrade
in-place from 8.4.x or earlier release to the upcoming release.
However, no format changes in the pg_largeobject catalog, including
an empty large object, so I guess we need a small amount of additional
support in pg_dump to create empty metadata.

I want any suggestion about here.

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Jaime Casanova on 6 Dec 2009 23:46
On Sun, Dec 6, 2009 at 11:19 PM, Greg Smith <greg(a)2ndquadrant.com> wrote:
> I just looked over the latest version of this patch and it seems to satisfy
> all the issues suggested by the initial review.  This looks like it's ready
> for a committer from a quality perspective and I'm going to mark it as such.
>

yes. i have just finished my tests and seems like the patch is working
just fine...

BTW, seems like KaiGai miss this comment in
src/backend/catalog/pg_largeobject.c when renaming the parameter
* large_object_privilege_checks is not refered here,

i still doesn't like the name but we have changed it a lot of times so
if anyone has a better idea now is when you have to speak

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: KaiGai Kohei on 7 Dec 2009 00:07
Jaime Casanova wrote:
> On Sun, Dec 6, 2009 at 11:19 PM, Greg Smith <greg(a)2ndquadrant.com> wrote:
>> I just looked over the latest version of this patch and it seems to satisfy
>> all the issues suggested by the initial review. This looks like it's ready
>> for a committer from a quality perspective and I'm going to mark it as such.
>>
>
> yes. i have just finished my tests and seems like the patch is working
> just fine...
>
> BTW, seems like KaiGai miss this comment in
> src/backend/catalog/pg_largeobject.c when renaming the parameter
> * large_object_privilege_checks is not refered here,
>
> i still doesn't like the name but we have changed it a lot of times so
> if anyone has a better idea now is when you have to speak

Oops, it should be fixed to "lo_compat_privileges".
This comment also have version number issue, so I fixed it as follows:

BEFORE:
/*
* large_object_privilege_checks is not refered here,
* because it is a compatibility option, but we don't
* have ALTER LARGE OBJECT prior to the v8.5.0.
*/

AFTER:
/*
* The 'lo_compat_privileges' is not checked here, because we
* don't have any access control features in the 8.4.x series
* or earlier release.
* So, it is not a place we can define a compatible behavior.
*/

Nothing are changed in other codes, including something corresponding to
in-place upgrading. I'm waiting for suggestion.

Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(a)ak.jp.nec.com>
From: "Kevin Grittner" on 7 Dec 2009 11:13
KaiGai Kohei <kaigai(a)ak.jp.nec.com> wrote:

> Apart from SELinux, it is quite natural to apply any access
> controls on binary data. If we could not have any valid access
> controls, users will not want to store their sensitive
> information, such as confidential PDF files, as a large object.

Absolutely. The historical security issues for large objects
immediately eliminated them as a possible place to store PDF files.

-Kevin

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

 | 
Pages: 1
Prev: Hot standby, recent changes
Next: YAML