Re: Largeobject Access Controls (r2460)

Takahiro Itagaki wrote:
> 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?

Oops, I forgot to fix it.

It is a misconfiguration on database initialization, and not related
issue with SE-PgSQL feature.

It can be solved with revoking any privileges from anybody in the initdb
phase. So, we should inject the following statement for setup_privileges().

REVOKE ALL ON pg_largeobject FROM PUBLIC;

In the default PG model, database superuser is an exception in access
controls, so he can bypass the checks eventually. Here is no difference,
even if he can see pg_largeobject.
For unprivileged users, this configuration restricts the way to access
large object into lo_*() functions, so we can acquire all their accesses
and apply permission checks comprehensively.

When database superuser tries to consider something malicious, such as
exposing any large object to public, we have to give up anything.

> 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.

We already have COMMENT ON LARGE OBJECT <number> IS <comment>; statement :-)

> "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
>
>
>

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