Re: [HACKERS] permission issue
От | jwieck@debis.com (Jan Wieck) |
---|---|
Тема | Re: [HACKERS] permission issue |
Дата | |
Msg-id | m0y8MoF-000BFRC@orion.SAPserv.Hamburg.dsh.de обсуждение исходный текст |
Ответ на | permission issue ("Vadim B. Mikheev" <vadim@sable.krasnoyarsk.su>) |
Список | pgsql-hackers |
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) #
В списке pgsql-hackers по дате отправления: