Skip site navigation (1) Skip section navigation (2)

Re: Largeobject Access Controls (r2460)

From: Takahiro Itagaki <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
To: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
Cc: Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>, Greg Smith <greg(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Largeobject Access Controls (r2460)
Date: 2009-12-10 05:56:56
Message-ID: 20091210145656.1B6B.52131E4D@oss.ntt.co.jp (view raw or flat)
Thread:
Lists: pgsql-hackers
Hi, I'm reviewing LO-AC patch.

KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com> wrote:
> Nothing are changed in other codes, including something corresponding to
> in-place upgrading. I'm waiting for suggestion.

I have a question about the behavior -- the patch adds ownership
management of large objects. Non-privileged users cannot read, write,
or drop othere's LOs. But they can read the contents of large object
when they read pg_catalog.pg_largeobject directly. Even if the patch
is applied, we still allow "SELECT * FROM pg_largeobject" ...right?

This issue might be solved by the core SE-PgSQL patch,
but what should we do fo now?


Other changes in the patch seem to be reasonable.

"GRANT/REVOKE ON LARGE OBJECT <number>" might be hard to use if used alone,
but we can use the commands as dynamic SQLs in DO statements if we want to
grant or revoke privileges in bulk.

"SELECT oid FROM pg_largeobject_metadata" is used in some places instead of
"SELECT DISTINCT loid FROM pg_largeobject". They return the same result,
but the former will be faster because we don't use DISTINCT. pg_dump will
be slightly accelerated by the new query.

Regards,
---
Takahiro Itagaki
NTT Open Source Software Center



In response to

Responses

pgsql-hackers by date

Next:From: Takahiro ItagakiDate: 2009-12-10 06:24:44
Subject: random() in multi-threaded pgbench
Previous:From: Tom LaneDate: 2009-12-10 04:33:39
Subject: Re: unprivileged user

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group