Re: [GENERAL] Strange permission problem regarding pg_settings - Mailing list pgsql-hackers

From Joe Conway
Subject Re: [GENERAL] Strange permission problem regarding pg_settings
Date
Msg-id 3FEDF71A.5030001@joeconway.com
Whole thread Raw
In response to Re: [GENERAL] Strange permission problem regarding pg_settings  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [GENERAL] Strange permission problem regarding pg_settings
List pgsql-hackers
Tom Lane wrote:
> Reverting the change will bring back the bug for which it was created.
> It does seem though that we have an inadequate model of how to perform
> permission checks.  In particular, the "write" flag bit in RTEs is
> context dependent: it can mean insert, update, or delete permission
> depending on the surrounding command.

Sorry if I'm being thick, but what of this?
> regression=> insert into table1 values (1);> NOTICE:  relOid = 1245674> NOTICE:  userid = 101> NOTICE:  operation =
CMD_INSERT>NOTICE:  relOid = 1245674> NOTICE:  userid = 101> NOTICE:  operation = CMD_UPDATE> ERROR:  table1:
permissiondenied>> regression=> select oid, relname from pg_class where relname like 
 
'table%';>    oid   | relname> ---------+--------->  1245674 | table1>  1245676 | table2> (2 rows)

Given how rules are supposed to work, the first check looks correct:  INSERT on table1 checked as pleb, userid = 101

But the second check is incorrect, not because of the mode being 
checked, but because of the reloid and userid. The second check should be:  UPDATE on table2 checked as postgres,
userid= 1
 

So why doesn't the second rte refer to table2 and userid=1?

Joe




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Error with returning SETOF Record
Next
From: A E
Date:
Subject: Re: Error with returning SETOF Record