Re: [pgsql-patches] [HACKERS] less privileged pl install

On Tue, 20 Feb 2007, Bruce Momjian wrote:

>
> The most recent version of this patch has been added.
>
> Your patch has been added to the PostgreSQL unapplied patches list at:
>
> http://momjian.postgresql.org/cgi-bin/pgpatches
>
> It will be applied as soon as one of the PostgreSQL committers reviews
> and approves it.

Cool, I was going to bring this up again once the regexp patch got in.
There is one thing in this patch I was not sure on, and that is in
AlterLanguageOwner what should the second parameter of heap_close be? I
have RowExclusiveLock in the patch, but I am not sure that is correct.
It would be good if someone more knowledgeable about such things checked
on this when applying it...

The latest version of the patch is currently at
http://momjian.us/mhonarc/patches/msg00014.html

> ---------------------------------------------------------------------------
>
>
> Jeremy Drake wrote:
> > 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
> Content-Description:
>
> [ Attachment, skipping... ]
>
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 6: explain analyze is your friend
>
>

--
A UNIX saleslady, Lenore,
Enjoys work, but she likes the beach more.
She found a good way
To combine work and play:
She sells C shells by the seashore.