Re: Must be owner to truncate?

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Manfred Koizar <mkoi-pg(at)aon(dot)at>
Cc: Andreas Seltenreich <andreas+pg(at)gate450(dot)dyndns(dot)org>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Jim C(dot) Nasby" <decibel(at)decibel(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Postgres Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Must be owner to truncate?
Date: 2005-08-24 12:48:36
Message-ID: 20050824124836.GM6026@ns.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Manfred Koizar (mkoi-pg(at)aon(dot)at) wrote:
> On Wed, 24 Aug 2005 07:01:00 +0200, Andreas Seltenreich
> <andreas+pg(at)gate450(dot)dyndns(dot)org> wrote:
> >However, a question arose quickly: According to the standard, revoking
> >INSERT, UPDATE and DELETE after GRANT ALL PRIVILEGES would leave the
> >relation read-only, but with the TRUNCATE privilege lying around, this
> >would no longer be true for PostgreSQL.
>
> I'd say that the TRUNCATE privilege includes DELETE, so that REVOKE
> DELETE implicitly revokes TRUNCATE and GRANT TRUNCATE implicitly
> grants DELETE.

I disagree with implicitly granting/revokeing. Rather, if we're going
to go this route, we should require both DELETE and TRUNCATE rights on
the object in order to TRUNCATE it but otherwise have TRUNCATE
privileges and DELETE privileges be distinct from each other in terms of
being granted/revoked.

This follows the SELECT/UPDATE relationship. Granting UPDATE doesn't
implicitly grant SELECT, and revoking SELECT doesn't implicitly revoke
UPDATE; but in order to actually UPDATE you need SELECT rights.

Thanks,

Stephen

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2005-08-24 12:49:15 Re: ECPG and escape strings
Previous Message Stephen Frost 2005-08-24 12:44:29 Re: Must be owner to truncate?