Обсуждение: 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 #