Fwd: [Patch Review] TRUNCATE Permission

I had intended to send this message to the pgsql-hackers mailing list as
well.

Thanks,

- Ryan

---------- Forwarded message ----------
From: Ryan Bradetich <rbradetich(at)gmail(dot)com>
Date: Mon, Sep 1, 2008 at 2:20 PM
Subject: Re: [HACKERS] [Patch Review] TRUNCATE Permission
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>

Hello Tom,

On Mon, Sep 1, 2008 at 1:00 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> "Ryan Bradetich" <rbradetich(at)gmail(dot)com> writes:
> >> I do not believe this is a huge issue since truncate is prohibited on
> the
> >> system catalogs
> >> by the truncate_check_rel().
>
> Only when allowSystemTableMods is false. I think it would be a serious
> mistake for your patch to treat the system catalogs differently from
> other tables.
>

Good Point. Looks like I still have more code reading to do :)

This is Robert Haas's patch for the September 2008 commit-fest.
I am just offering my review. Gives me a good excuse to dig into
the PostgreSQL code base. Hopefully this review is useful to the
person committing the patch.

> > Here is the inconsistency I observed:
>
> It seems to me that you are assuming that lack of a TRUNCATE permission
> bit is the only valid reason for a "permission denied" failure. This is
> fairly obviously not so, since multiple permissions typically enter into
> any command (consider schema-level permissions for instance).
>

I was just comparing the behavior between DELETE and TRUNCATE.
My last suggestion for the TRUNCATE permission always being removed
on the system tables is obviously bogus because of the allowSystemTableMods
issue you raised.

Does my first suggestion still make sense for removing the TRUNCATE in
pg_class_aclmask() when pg_Authid.rolcatupdate is not set?

Thanks,

- Ryan