Re: [HACKERS] less privileged pl install

On Thu, 25 Jan 2007, Jeremy Drake wrote:

> On Thu, 25 Jan 2007, Jeremy Drake wrote:
>
> > I think that an ALTER LANGUAGE OWNER TO is the proper response to these
> > things, and unless I hear otherwise I will attempt to add this to my
> > patch.
>
> Here is the patch which adds this. It also allows ALTER LANGUAGE RENAME
> TO for the owner, which I missed before. I would appreciate someone with
> more knowledge of the permissions infrastructure to take a look at it
> since I am fairly new to it and may not fully understand its intricacies.
>

I have refactored the owner checking of languages in the same manner as it
is for other owned objects. I have changed to using standard permissions
error messages (aclcheck_error) for the language permissions errors.

I consider this patch ready for review, assuming the permissions rules
outlined by Tom Lane on -hackers are valid. For reference, here are the
rules that this patch is intended to implement:

On Wed, 24 Jan 2007, Tom Lane wrote:

> In detail, it'd look something like:
>
> * For an untrusted language: must be superuser to either create or use
> the language (no change from current rules). Ownership of the
> pg_language entry is really irrelevant, as is its ACL.
>
> * For a trusted language:
>
> * if pg_pltemplate.something is ON: either a superuser or the current
> DB's owner can CREATE the language. In either case the pg_language
> entry will be marked as owned by the DB owner (pg_database.datdba),
> which means that subsequently he (or a superuser) can grant or deny
> USAGE within his DB.
>
> * if pg_pltemplate.something is OFF: must be superuser to CREATE the
> language; subsequently it will be owned by you, so only you or another
> superuser can grant or deny USAGE (same behavior as currently).

The only difference from this is, that when superuser is required, the
owner of the language is not the superuser who created it, but
BOOTSTRAP_SUPERUSERID. This is because my interpretation was that the
"same behavior as currently" took precedence. The current behavior in cvs
is that languages have no owner, and for purposes where one would be
needed it is assumed to be BOOTSTRAP_SUPERUSERID.

Is this valid, or should I instead set the owner to GetUserId() in those
cases?

--
Academic politics is the most vicious and bitter form of politics,
because the stakes are so low.
-- Wallace Sayre