Security again

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(at)debis(dot)com (Jan Wieck) #