* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> 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?

Being able to delete all data in a given table in no way implies
ownership rights.  The tables are part of a specification which the
users are being asked to respond to.  Being able to change the table
types or remove the constraints put on the tables would allow the 
users to upload garbage which would then affect downstream processing.

We can't guarentee this won't happen anyway but we try to confine the
things they can mess up to a reasonable set which we can check for (and
do, through a rather involved error checking system).  There are *alot*
of things built on top of the table structures and having them change
would basically break the whole system (without the appropriate changes
being made to the other parts of the system).

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

I don't think anyone's asked for 'ALTER TABLE' privileges to be
seperately grantable.  It seems to me that the privileges which *need*
to be grantable are ones associated with DML statements.  I would 
classify TRUNCATE, VACUUM and ANALYZE as DML statements (along with 
select, insert, update, and delete).  They're PostgreSQL-specific DML 
statements but they still fall into that category.  I don't think 
it's a coincidence that the SQL-defined DML statements are all, 
individually, grantable.

That doesn't mean I think we should get rid of RULE, REFERENCES or
TRIGGER, though honestly I've very rarely needed to grant any of them 
(I don't think I've ever granted RULE or TRIGGER...).  References is
DDL-oriented, but for *other* tables; RULE and TRIGGER are DDL and I
can't really justify why someone other than the owner would need them
but I'm guessing someone's using them.  I don't think their existance
should imply that if we ever change the grants again we have to include
all types of 'ALTER TABLE', etc, though.

	Thanks,

		Stephen

In response to

• Re: [Bizgres-general] WAL bypass for INSERT, UPDATE and at 2006-01-03 17:37:32 from Tom Lane

pgsql-hackers by date

Next:	From: Alfranio Correia Junior	Date: 2006-01-03 19:11:14
	Subject: Re: HOOKS for Synchronous Replication?
Previous:	From: Tom Lane	Date: 2006-01-03 18:21:52
	Subject: Re: Why don't we allow DNS names in pg_hba.conf?