Обсуждение: create view security
Hi All, I am trying to enable my web site to create views in a database owned by a user called ddirpts. Now, the web server runs as nobody, and nobody has a user and database set up in Postgres.. But the problem is, whenever I have a cgi program issue a create view query on the ddirpts database, the backend reports Parse error at or near "". I can however issue create view commands as ddirpts. I was thinking this might be a security restriction, wherein no user can create views/tables in another user's database without some kind of special permission--problem is, how do I create the permission? I am using 6.3 in this case. _________________________________________________ Ted Wallingford Manager of Information Technology Independence Excavating, Inc. Precision Environmental Co. Independence Communications, Inc. www.indexc.com > -----Original Message----- > From: Thomas Lockhart [mailto:lockhart@alumni.caltech.edu] > Sent: Tuesday, May 30, 2000 10:04 PM > To: Tom Lane > Cc: Peter Eisentraut; Joseph Shraibman; pgsql-sql@postgresql.org; > pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Re: [SQL] aliases break my query > > > > At one time Bruce had made some patches to emit informative notice > > messages about implicit FROM entries, but that got turned off again > > for reasons that I forget... > > It was triggered with common cases from the "outer join" > syntax. It took > a while to track down since it was introduced while I was > working on the > syntax feature :( > > If it *really* needs to be put back in, then we should do so > with a flag > so we can disable the warning at compile time, run time, and/or in the > outer join parser area. But imho sprinkling the parser with > warnings for > allowed syntax is heading the wrong direction. If it is > legal, allow it. > If it is illegal, disallow it. If it is confusing for some, but works > fine for others, it shouldn't become "sort of legal" with a warning. > > - Thomas >
Вложения
Wallingford, Ted writes: > I am using 6.3 in this case. I'm sorry but that is pre-historic era around here and no one really remembers what the problems might have been back then (other than that they were surely plenty). Upgrading might be your best bet on all fronts. -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
Peter Eisentraut wrote: > Wallingford, Ted writes: > > > I am using 6.3 in this case. > > I'm sorry but that is pre-historic era around here and no one really > remembers what the problems might have been back then (other than that > they were surely plenty). Upgrading might be your best bet on all fronts. You're wrong - I remember, not 100% sure, but good enough. Just two weeks ago (funny - isn't it) I made a deal with a friend, exchanging this old 486/33DLC, 8MB, 1GB portable (640x480 gray but onboard SCSI!) with a planimeter (nice mechanic tool that fit's perfectly into my sliderule collection - that friend collects sliderules too so he knows how to get me :-). That old portable was the computer, most of the rule system fixes for v6.4 where developed on. I'm pretty sure that the Rule-Owner-Needs-Perm changes where part of it. The executor is doing a permisson check of the result- and all scan relations just before starting the execution. For v6.4 (or was THAT in 6.5 - dunno exactly) I added a little flag to the rangetable entry that tells "this relation is accessed through a view and permissions are already checked". Since then, it was the rewriter that checked if the view- owner would have the permissions for all relations used by the view. Anyway, upgrading IS the best (if not the only) choice for him. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #