Re: [PATCHES] [pgsql-patches] [HACKERS] less privileged pl install
Jeremy Drake <[EMAIL PROTECTED]> writes: > On Mon, 26 Mar 2007, Tom Lane wrote: >> Applied with minor revisions --- in particular, I thought the initial >> owner of a language should be its creator, full stop, rather than the >> rather strange (and undocumented) behavior you had. > The reason I did it like that was this email from you: > http://archives.postgresql.org/pgsql-hackers/2007-01/msg01186.php Yeah, but that idea predated the addition of ALTER LANGUAGE OWNER to the patch. Given that, a superuser can give away the language to someone else if he wants, and so there's no need for us to try to be fancy about guessing what he wants (which was more or less what that rule was). regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [pgsql-patches] [HACKERS] less privileged pl install
On Mon, 26 Mar 2007, Tom Lane wrote: > Jeremy Drake <[EMAIL PROTECTED]> writes: > > This version of the patch includes documentation changes. Please > > review... > > Applied with minor revisions --- in particular, I thought the initial > owner of a language should be its creator, full stop, rather than the > rather strange (and undocumented) behavior you had. The reason I did it like that was this email from you: http://archives.postgresql.org/pgsql-hackers/2007-01/msg01186.php > Also you missed updating pg_dump. Indeed. Now, all I need is the 'tsearch2 in core' patch to go in, and 8.3 will solve almost all of my problems :) Then I just need to nag my hosting provider to upgrade once it is released. I have been refraining from nagging about them still running 8.1.3 in anticipation of this ;) -- Five is a sufficiently close approximation to infinity. -- Robert Firth ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] [pgsql-patches] [HACKERS] less privileged pl install
Jeremy Drake <[EMAIL PROTECTED]> writes: > This version of the patch includes documentation changes. Please > review... Applied with minor revisions --- in particular, I thought the initial owner of a language should be its creator, full stop, rather than the rather strange (and undocumented) behavior you had. Also you missed updating pg_dump. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [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. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] [pgsql-patches] [HACKERS] less privileged pl install
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. --- 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 -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
