Thread

1. permission issue

   Vadim Mikheev <vadim@sable.krasnoyarsk.su> — 1998-02-27T07:30:08Z

   Tables INS (x int) and SEL (y int) are owned by dbadm, for another
   user SELECT granted on SEL, INSERT - on INS.
   
   Should another user be able to do
   
   insert into ins select y from sel where x = y;
   
   or not ? 
   Currently, PG allows this. Backend tries to check 
   (in execMain.c:ExecCheckPerms()) is READ access to
   table being changed granted to user or not, but this check
   seems to be quite stupid:
   
               qvars = pull_varnos(parseTree->qual);
               tvars = pull_varnos((Node *) parseTree->targetList);
               if (intMember(resultRelation, qvars) ||
                   intMember(resultRelation, tvars))
   
   : pull_varnos is very simple and just skips expressions in
   qual & target list.
   
   We have to either get rid of this check or change it.
   
   What do you think ?
   How "big boys" handle this ?
   
   Vadim
   
   

2. Re: [HACKERS] permission issue

   Jan Wieck <jwieck@debis.com> — 1998-02-27T10:14:27Z

   Vadim wrote:
   
   >
   > Tables INS (x int) and SEL (y int) are owned by dbadm, for another
   > user SELECT granted on SEL, INSERT - on INS.
   >
   > Should another user be able to do
   >
   > insert into ins select y from sel where x = y;
   >
   > or not ?
   > Currently, PG allows this. Backend tries to check
   > (in execMain.c:ExecCheckPerms()) is READ access to
   > table being changed granted to user or not, but this check
   > seems to be quite stupid:
   >
   >             qvars = pull_varnos(parseTree->qual);
   >             tvars = pull_varnos((Node *) parseTree->targetList);
   >             if (intMember(resultRelation, qvars) ||
   >                 intMember(resultRelation, tvars))
   >
   > : pull_varnos is very simple and just skips expressions in
   > qual & target list.
   >
   > We have to either get rid of this check or change it.
   >
   > What do you think ?
   > How "big boys" handle this ?
   >
   > Vadim
   >
   >
   
       As  I  wrote  we  must change more on the permission checking
       than currently done. I plan to implement  something  like  an
       effective  user  which is used instead of the current user in
       the checks and switch the effective user on function calls to
       the  owner  of  the  function  (triggers  are  implemented as
       functions and thus also covered). And we need that  effective
       user  too  for the checks in views instead of what we did now
       with skipAcl in the RTE.
   
       I'll keep the above words in mind when doing  so.  But  first
       let's release 6.3.
   
   
   Jan
   
   --
   
   #======================================================================#
   # It's easier to get forgiveness for being wrong than for being right. #
   # Let's break this rule - forgive me.                                  #
   #======================================== jwieck@debis.com (Jan Wieck) #
   
   
   
   

3. Re: [HACKERS] permission issue

   Bruce Momjian <maillist@candle.pha.pa.us> — 1998-02-27T15:06:31Z

   > 
   > Tables INS (x int) and SEL (y int) are owned by dbadm, for another
   > user SELECT granted on SEL, INSERT - on INS.
   > 
   > Should another user be able to do
   > 
   > insert into ins select y from sel where x = y;
   
   My guess is that the other user doesn't have SELECT permissions on
   INS.y, so this should fail, no?
   
   > 
   > or not ? 
   > Currently, PG allows this. Backend tries to check 
   > (in execMain.c:ExecCheckPerms()) is READ access to
   > table being changed granted to user or not, but this check
   > seems to be quite stupid:
   > 
   >             qvars = pull_varnos(parseTree->qual);
   >             tvars = pull_varnos((Node *) parseTree->targetList);
   >             if (intMember(resultRelation, qvars) ||
   >                 intMember(resultRelation, tvars))
   > 
   > : pull_varnos is very simple and just skips expressions in
   > qual & target list.
   > 
   > We have to either get rid of this check or change it.
   > 
   > What do you think ?
   > How "big boys" handle this ?
   > 
   > Vadim
   > 
   > 
   
   
   -- 
   Bruce Momjian                          |  830 Blythe Avenue
   maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
     +  If your life is a hard drive,     |  (610) 353-9879(w)
     +  Christ can be your backup.        |  (610) 853-3000(h)