Re: TRUNCATE, VACUUM, ANALYZE privileges

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: TRUNCATE, VACUUM, ANALYZE privileges
Date: 2006-01-04 11:51:02
Message-ID: 20060104115102.GT6026@ns.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > The following patch implements individual privileges for TRUNCATE,
> > VACUUM and ANALYZE. Includes documentation and regression test
> > updates. Resolves TODO item 'Add a separate TRUNCATE permission'.
>
> > At least the 'no one interested has written a patch' argument is gone
> > now, fire away with other comments/concerns. :)
>
> I have a very serious problem with the idea of inventing individual
> privilege bits for every maintenance command in sight. That does not
> scale. How will you handle "GRANT ADD COLUMN", or "GRANT ADD COLUMN
> as-long-as-its-not-SERIAL-because-I-dont-want-you-creating-sequences",
> or "GRANT ALTER TABLE RELIABILITY" as soon as someone writes that patch,
> or a dozen other cases that I could name without stopping for breath?

GRANT ADD COLUMN, etc, aren't maintenance commands, they're DDL
statements and as such should be the purview of the owner. TRUNCATE,
VACUUM and ANALYZE are DML commands and are commands a user of
the table would use through the normal course of inserting, updating or
deleteing data in the table.

> The proposed patch eats three of the five available privilege bits (that
> is, available without accepting the distributed cost of enlarging ACL
> bitmasks), and you've made no case at all why we should spend that
> limited resource in this particular fashion.

I've shown a specific use-case for this. It's been asked for before by
others. I've shown why these particular ones make sense (while 'ADD
COLUMN', etc, don't). If we come up with more Postgres-specific DML
statements which aren't covered by other grants (which doesn't seem
terribly likely at this point) then we should add those. I could see
making VACUUM and ANALYZE use the same bit (since one implies the other)
but I'm not really a big fan of that and I don't see any other need for
these bits coming down the line anytime soon.

Thanks,

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2006-01-04 11:55:44 Re: TRUNCATE, VACUUM, ANALYZE privileges
Previous Message Gregor Zeitlinger 2006-01-04 09:30:24 Re: Incremental Backup Script

Browse pgsql-patches by date

  From Date Subject
Next Message Stephen Frost 2006-01-04 11:55:44 Re: TRUNCATE, VACUUM, ANALYZE privileges
Previous Message Mahmoud Taghizadeh 2006-01-04 09:11:08 farsi translation: file fa_IR.po updated.