Stephen Frost <[EMAIL PROTECTED]> writes: > The code I had for this was:
> if (!pg_class_ownercheck(tuple,GetUserId()) || > !is_role_member(newowner,GetUserId())) > That needs a check for superuser though because while the test will pass > on the 'pg_class_ownercheck' side, it won't on the 'is_role_member' side Um, right, that was another problem I had with it --- at one point the regression tests were failing because the superuser wasn't allowed to reassign object ownership ... I'm still fairly concerned about the security implications of letting ordinary users reassign object ownership. The fact that SET ROLE would let you *create* an object with ownership X is a long way away from saying that you should be allowed to change an *existing* object to have ownership X. This is particularly so if you are a member of a couple of different roles with different memberships: you will be able to cause objects to become effectively owned by certain other people, or make them stop being effectively owned by those people. I don't have a clear trouble case in mind at the moment, but this sure sounds like the stuff of routine security-hole reports. (Altering the ownership of a SECURITY DEFINER function, in particular, sounds like a great path for a cracker to pursue.) > One place I recall seeing one and not being sure if it should be a new > *_ownercheck() function or not was in the 2PC patch- twophase.c, line > 380: This one I think we can leave... regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match