Re: [HACKERS] Permissions on copy

Andreas wrote:
>
> Since the copy statement is behaving differently than the normal select
> stuff,
> I think we should eighter introduce a new permission (name it copy or dump)
> or include the copy into the rewrite system.
>
> I would vote for the first and implement a new command:
>    unload to <filename> [delimiter '|'] <select statement>;    -- and
>    load from <filename> [delimiter '|'] <insert statement>;
> that does behave like the select.      (please forgive my Informix
> background)

    Since  the  copy  command  checks for ACL_RD or ACL_WR on the
    relation a user can use copy  on  any  table,  where  he  has
    propper permissions.

    And  triggers are fired too on COPY FROM (thanks for the push
    - found another place relevant for setuid triggers).

    The only things not working for copy are rewrite rules. But I
    think  we  should  restrict rules to the view handling in the
    future and move forward by implementing  a  pure  and  really
    powerful procedural language.

    I  vote  for  leaving copy as it is and take a look if we can
    fire triggers on SCAN which then could modify tuples  instead
    of  using  rules  at  all.  If the time an ON SCAN trigger is
    fired  is  just  before   the   evaluation   of   any   query
    qualification  and  put  down  into  the heap access methods,
    anything should be fine except for performance maybe (but  as
    I usually say: don't force it - use a bigger hammer).

>
> As to the topic with setuid triggers and others, I think setuid procedures
> would be sufficient.
> These are implemented in Informix with the following simple syntax:
> create dba procedure ....

    Looks good. Alternatively/additionally something like

    ALTER FUNCTION funcname (argtypes) { SETUID | NOSETUID }

    might  be  useful.  Parser  etc. steps could mostly be copied
    from the DROP FUNCTION ... statement. And we have  an  unused
    boolean  attribute  proistrusted in the pg_proc struct. If we
    rename that to proissetuid anything is fine.

    As I said I already fiddled around with that and  got  setuid
    functions  and triggers working (don't ask for code - usually
    I make a copy of the source tree, hack in totally ugly things
    until  I know how to do it and throw anything away to be sure
    only development not hacking get's into PostgreSQL).


Until later, 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) #