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

Re: [Bizgres-general] WAL bypass for INSERT, UPDATE and

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, kleptog(at)svana(dot)org, simon(at)2ndquadrant(dot)com, gsstark(at)mit(dot)edu, pg(at)rbt(dot)ca, zhouqq(at)cs(dot)toronto(dot)edu, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [Bizgres-general] WAL bypass for INSERT, UPDATE and
Date: 2006-01-03 17:37:32
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Stephen Frost <sfrost(at)snowman(dot)net> writes:
> The problem is that you might want to grant 'truncate' to people who
> *aren't* particularly trusted.  For truncate, at least I have a
> real-world use-case for it.

I don't find this use-case particularly convincing.  If the users are
allowed to delete all data in a given table, then that table must be
dedicated to them anyway; so it's not that easy to see why you can't
risk giving them ownership rights on it.  The worst they can do is
screw up their own data, no?

In any case, I don't see what's so wrong with the model of using
SECURITY DEFINER interface functions when you want a security
restriction that's finer-grain than the system provides.  I really
*don't* want to see us trying to, say, categorize every variety of
ALTER TABLE as a separately grantable privilege.  I could live with
something like a catchall "ADMIN" privilege ... except it's not
clear how that would differ from ownership.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2006-01-03 17:43:03
Subject: Re: Why don't we allow DNS names in pg_hba.conf?
Previous:From: Andrew DunstanDate: 2006-01-03 17:34:59
Subject: Re: Why don't we allow DNS names in pg_hba.conf?

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