From: "Tomasz Myrta" <jasiek@klaster.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: "'pgsql-sql@postgresql.org'" <pgsql-sql@postgresql.org>
Subject: Re: function with security definer 
Date: Mon, 24 Mar 2003 19:16:55 +0800
Message-Id: <20030324191655.M26247@klaster.net>
In-Reply-To: <12693.1048518122@sss.pgh.pa.us>
References: <3E7ED5EE.9090104@klaster.net> <12693.1048518122@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-2

> Tomasz Myrta <jasiek@klaster.net> writes:
> > [ Can't do SET SESSION AUTHORIZATION in a postgres-owned function ]
> 
> That's because SET SESSION AUTHORIZATION looks to the original login
> userid, not the current effective userid, to decide whether you're
> allowed to do it.  If it didn't work that way, a superuser couldn't
> switch to any other identity after becoming a nonprivileged user.
Does it mean, that SET SESSION AUTHORIZATION works the same for function 
created with "security definer" as with "security invoker"? Are there any 
other cases, when it doesn't work properly?
 
> I don't really see why you think this kluge is better than creating
> multiple database users, anyway ...
Well, it was just an idea. It is easier to keep all information about users 
in one table "users" than synchronizing this table with pg_shadow via 
usesysid and granting/revoking each user one by one (or adding them to 
groups). It lets me also to give each user as little rights as needed - even 
depending on which application they currently run (administration panel or 
web report)

Regards,
Tomasz Myrta