Re: [PATCHES] initdb authentication
This one makes it mandatory to pick some kind of authentication. If that's not wanted, it's easy to change it to default to trust (which I think is wrong, but we've been through that already..) I don't think I like any of this. Sooner rather than later, people need to look at pg_hba.conf and think about it. I don't like switches that induce them to skip that step. My guess is that a whole lot (I'd go as far as to say most) users don't do this. Instead they start the system in whatever is default, *and think it's secure enough*. Therefor, the default should be a reasonable guess at the securest thing they want. And setting trust is not that. Sort of like MSSQL permitting and defaulting to a blank sa password in earlier versions. Even MS fixed that. Yes, it took a worm for them to do it, but they did... If you want to fix that the whole way, install a pg_hba.conf *without anything*. That way nobody can connect and use their database until they edit it. (Turns out that is the same thing my patch does except it lets you set it on the commandline to initdb instead of having to edit the file assuming you just want local auth) And I certainly don't like forcing extra switches on users that just try out an installation locally. Oh, you mean along the line of having to create a separate user account to run it under? I'd say that is a whole lot more work than just entering a password. Or *explicitly* chosing that you want trust authentication. This very argument was shot down pretty quickly last time it came up in just a slightly different context, but it keeps popping up... I would be in favor of making everything supertight and secure by default, no questions asked. The is a definable goal. But as long as there is no agreement on that, let's not create illusions in that direction while inconveniencing a bunch of people for little gain. I think the basic problem is that right now there is no way to do an initdb and have it be secure _before_ you edit pg_hba.conf. That isn't acceptable. My thoughts exactly. Because most users *will not* edit pg_hba.conf until they need it to enable something, this is a problem. If I am on an insecure machine, the window if time between initdb and editing of pg_hba.conf is pretty bad. I could edit pg_hba.conf.sample, but then I am editing a sample file. Um. No. initdb does not start the database. You're safe until you start postmaster. This is defence against the fact that most users will start the database without editing (or looking at, or for that matter even be aware of the existance of) pg_hba.conf. I think Magnus's patch takes us closer to secure. I do agree that by default we shouldn't require any flag and install unsecure and issue a warning. I say that warning should be in the form of if you realy want this, append --trust to the command you just issued, but any step towards it is a step in the right direction :-) //Magnus ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] plperl win32
Magnus, why is this reassignment needed, basically the 'else' part: ! ifeq ($(PORTNAME), win32) ! xperl_archlibexp=$(subst \,/,$(perl_archlibexp)) ! xperl_privlibexp=$(subst \,/,$(perl_privlibexp)) ! perl_embed_ldflags=-L $(xperl_archlibexp)/CORE -lperl58 ! else ! xperl_archlibexp=$(perl_archlibxep) ! xperl_privlibexp=$(perl_privlibexp) ! endif --- Magnus Hagander wrote: Here is a patch required to build plperl with win32. The issues were: * perl_useshrplib gets set to yes and not to true. I assume it's set to true on unix, so I left both. * Need to translate backslashes into slashes * The linker config coming out of perl was for MSVC and not for mingw Some of this is pretty ugly stuff - the reassigning into a second variable etc. If somebody with a little better makefile knowledge would clean that up (if it can be, but it should be possible), please do! //Magnus plperl_win32.patch Content-Description: plperl_win32.patch [ Attachment, skipping... ] ---(end of broadcast)--- TIP 8: explain analyze is your friend -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] plperl win32
Magnus, why is this reassignment needed, basically the 'else' part: ! ifeq ($(PORTNAME), win32) ! xperl_archlibexp=$(subst \,/,$(perl_archlibexp)) ! xperl_privlibexp=$(subst \,/,$(perl_privlibexp)) ! perl_embed_ldflags=-L $(xperl_archlibexp)/CORE -lperl58 ! else ! xperl_archlibexp=$(perl_archlibxep) ! xperl_privlibexp=$(perl_privlibexp) ! endif Most likely because I'm not experienced enough at writing makefiles ;-) I originally tried the approach with ifeq ($(PORTNAME),win32) perl_archlibexp=$(subst, \,/,$(perl_archlibexp)) ... but then make complained about recursive assignment of the variable. If there is a simple way to get around that, it wouldn't be necessary. Since I didn't know of one, I had to change the name of the variable, which in turned required the part under else, so I didn't have to ifeq the actual build rule. //Magnus ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] plperl win32
Magnus Hagander [EMAIL PROTECTED] writes: I originally tried the approach with ifeq ($(PORTNAME),win32) perl_archlibexp=$(subst, \,/,$(perl_archlibexp)) ... but then make complained about recursive assignment of the variable. If there is a simple way to get around that, it wouldn't be necessary. Use := not = ... When you write foo = something, you are defining something that acts like a macro rather than a constant string, and so the above is a self-referential macro. In particular $(x) references are not expanded yet in something that's assigned with =. Here is an example of the difference: x = foo y = bar$(x) x = baz If you now evaluate $(y) you will get barbaz, not barfoo (in fact, there is no need to define x before y at all in this case). On the other hand, in x = foo y := bar$(x) y is assigned barfoo, and it won't change if x is modified later. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] initdb authentication
Here's a version of this patch that includes documentation updates. //Magnus -Original Message- From: Magnus Hagander Sent: den 15 juli 2004 23:02 To: [EMAIL PROTECTED] Subject: [PATCHES] initdb authentication Ok, here is one more try at the initdb default authentication stuff. This one adds the switches --ident and --trust, which will configure pg_hba.conf with ident and trust authentication respectively. If trust authentication is selected, a warning is written to pg_hba.conf. The old switches for password prompt/file still apply. This one makes it mandatory to pick some kind of authentication. If that's not wanted, it's easy to change it to default to trust (which I think is wrong, but we've been through that already..) Oh, and this time, the comments are updated :-) //Magnus initdb_auth.patch Description: initdb_auth.patch ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] Show tablespace name in pg_tables and pg_indexes
On Mon, 12 Jul 2004, Klaus Naumann wrote: Hi, I've sent this patch a while ago - was it applied? Is something not ok with it? Don't want to bug anyone - just would like to have some feedback. Grettings, Klaus On Mon, 12 Jul 2004, Klaus Naumann wrote: Hi, sorry, the last patch is buggy which didn't show up in the tests :( Two LEFTs were missing - new patch is attached. Greetings, Klaus Hi, the attached patch shows the new column tablespace in the mentioned views. Apply with ~/pgsql$ patch -p1 03_showtblspc.diff Greetings, Klaus -- Full Name : Klaus Naumann | (http://www.mgnet.de/) (Germany) Phone / FAX : ++49/177/7862964 | E-Mail: ([EMAIL PROTECTED]) ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] pg_autovacuum integration attempt #2
Matthew, were are we on this patch? --- Matthew T. O'Connor wrote: FYI, I am out of town from Friday 7/2 till Monday evening 7/5. I probably won't have email while I'm gone. I will continue working on this when I get back. Also, I have made a few minor tweaks since submitting this patch namely changing autovac_enabled to default to false. I am also trying to use a GUC assign hook function to require pgstat_collect_tuplelevel = true when autovac_enabled = true. The problem I'm running into is that the hook function seems to be getting called before the pgstat variables is set, thus the hook complains even when pgstat_collect_tuplelevel is set to true. Is there someway to force the order in which variables are read from GUC? Thanks, Matthew On Tue, 2004-06-29 at 10:44, Matthew T. O'Connor wrote: I have make the changes suggested after I posted my last patch, I have also make several additional improvements. it needs to be tested more, but since the deadline is coming up so soon, I wanted to post an update just to keep everyone abreast of what I'm doing. Please review and let me know what I need to change to get it applied to CVS. As before, this patch requires that pg_autovacuum.c and .h are moved from contrib to src/backend/postmaster and src/include/postmaster respectively. I have also attached the pg_autovacuum.h file that needs to be put in src/include/catelog/ for the new pg_autovacuum system table. I assume I will have to write the docs for this, but right now I'm focusing on the code, I get get the docs written after the feature freeze. Matthew O'Connor __ ---(end of broadcast)--- TIP 8: explain analyze is your friend ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] plperl win32
Attached is the modified patch I applied. Thanks. --- Magnus Hagander wrote: Here is a patch required to build plperl with win32. The issues were: * perl_useshrplib gets set to yes and not to true. I assume it's set to true on unix, so I left both. * Need to translate backslashes into slashes * The linker config coming out of perl was for MSVC and not for mingw Some of this is pretty ugly stuff - the reassigning into a second variable etc. If somebody with a little better makefile knowledge would clean that up (if it can be, but it should be possible), please do! //Magnus plperl_win32.patch Content-Description: plperl_win32.patch [ Attachment, skipping... ] ---(end of broadcast)--- TIP 8: explain analyze is your friend -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 Index: src/pl/plperl/GNUmakefile === RCS file: /cvsroot/pgsql-server/src/pl/plperl/GNUmakefile,v retrieving revision 1.14 diff -c -c -r1.14 GNUmakefile *** src/pl/plperl/GNUmakefile 5 Jul 2004 23:24:12 - 1.14 --- src/pl/plperl/GNUmakefile 16 Jul 2004 19:16:57 - *** *** 8,13 --- 8,16 ifeq ($(perl_useshrplib),true) shared_libperl = yes endif + ifeq ($(perl_useshrplib),yes) + shared_libperl = yes + endif # If we don't have a shared library and the platform doesn't allow it # to work without, we have to skip it. *** *** 18,24 override CFLAGS := $(filter-out -Wall -Wmissing-declarations -Wmissing-prototypes, $(CFLAGS)) endif ! override CPPFLAGS := -I$(srcdir) -I$(perl_archlibexp)/CORE $(CPPFLAGS) NAME = plperl --- 21,33 override CFLAGS := $(filter-out -Wall -Wmissing-declarations -Wmissing-prototypes, $(CFLAGS)) endif ! ifeq ($(PORTNAME), win32) ! perl_archlibexp := $(subst \,/,$(perl_archlibexp)) ! perl_privlibexp := $(subst \,/,$(perl_privlibexp)) ! perl_embed_ldflags := -L $(perl_archlibexp)/CORE -lperl58 ! endif ! ! override CPPFLAGS := -I$(srcdir) $(CPPFLAGS) -I$(perl_archlibexp)/CORE NAME = plperl ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] pg_autovacuum integration attempt #2
I think it's ready to apply barring any feedback to the contrary. Actually I do have a small improvement I will send in tomorrow (sorry can't do it any sooner) that defaulted autovac_enabled to false, and makes autovac fail more gracefully when the stats system is not enabled, but that shouldn't stop you from applying this patch. The thing I was trying to do was use the GUC hook function to make sure that the required GUC variables are also set before GUC reports autovac as enabled. This seemed cleaner to me, but apparently it won't work since it seems that autovac_enabled is read from GUC before the stats variables, and there is no way to force the order in which they are read. Am I missing something? Matthew Matthew, were are we on this patch? --- Matthew T. O'Connor wrote: FYI, I am out of town from Friday 7/2 till Monday evening 7/5. I probably won't have email while I'm gone. I will continue working on this when I get back. Also, I have made a few minor tweaks since submitting this patch namely changing autovac_enabled to default to false. I am also trying to use a GUC assign hook function to require pgstat_collect_tuplelevel = true when autovac_enabled = true. The problem I'm running into is that the hook function seems to be getting called before the pgstat variables is set, thus the hook complains even when pgstat_collect_tuplelevel is set to true. Is there someway to force the order in which variables are read from GUC? Thanks, Matthew On Tue, 2004-06-29 at 10:44, Matthew T. O'Connor wrote: I have make the changes suggested after I posted my last patch, I have also make several additional improvements. it needs to be tested more, but since the deadline is coming up so soon, I wanted to post an update just to keep everyone abreast of what I'm doing. Please review and let me know what I need to change to get it applied to CVS. As before, this patch requires that pg_autovacuum.c and .h are moved from contrib to src/backend/postmaster and src/include/postmaster respectively. I have also attached the pg_autovacuum.h file that needs to be put in src/include/catelog/ for the new pg_autovacuum system table. I assume I will have to write the docs for this, but right now I'm focusing on the code, I get get the docs written after the feature freeze. Matthew O'Connor __ ---(end of broadcast)--- TIP 8: explain analyze is your friend ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] pg_autovacuum integration attempt #2
Matthew T. O'Connor wrote: I think it's ready to apply barring any feedback to the contrary. Actually I do have a small improvement I will send in tomorrow (sorry can't do it any sooner) that defaulted autovac_enabled to false, and makes autovac fail more gracefully when the stats system is not enabled, but that shouldn't stop you from applying this patch. Great! The thing I was trying to do was use the GUC hook function to make sure that the required GUC variables are also set before GUC reports autovac as enabled. This seemed cleaner to me, but apparently it won't work since it seems that autovac_enabled is read from GUC before the stats variables, and there is no way to force the order in which they are read. Am I missing something? Oh, so that is the reason for asking about ordering. The only other case I have seen like this is for log_statement_stats: ereport(ERROR, (errcode(ERRCODE_INVALID_PARAMETER_VALUE), errmsg(cannot enable \log_statement_stats\ when \log_parser_stats\,\n \log_planner_stats\, or \log_executor_stats\ is true.))); The code works most of the time because it is checking to see if two values are set to non-defaults. In your case, you want to have both set to non-defaults for it to work. I can see that requiring ordering and I can't think of a way to fix that. If you put something in the code after the config file was read, how do you check later for cases where the user is using SET. Ah, I got it. The 'source' tells you if it is coming from a config file or from a user SET or something. You could do that check during the assignment when it is coming from SET, and add a function call after the config file is loaded for more global checks of multiple variables. Anyway, we can do that later. Let's set it to false and get it in. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] pg_autovacuum integration attempt #2
Matthew T. O'Connor wrote: I think it's ready to apply barring any feedback to the contrary. Actually I do have a small improvement I will send in tomorrow (sorry can't do it any sooner) that defaulted autovac_enabled to false, and makes autovac fail more gracefully when the stats system is not enabled, but that shouldn't stop you from applying this patch. A nitpick on that parameter name: There is not reason to abbreviate autovacuum: there is enough space. And the _enabled is redundant. The thing I was trying to do was use the GUC hook function to make sure that the required GUC variables are also set before GUC reports autovac as enabled. This seemed cleaner to me, but apparently it won't work since it seems that autovac_enabled is read from GUC before the stats variables, and there is no way to force the order in which they are read. Am I missing something? What I am missing at least is what you really mean by the required GUC variables are also set. GUC variables are always set to something (at least after the initialization phase, but you don't get to do anything with GUC before the initialization, obviously). -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] initdb authentication
I got a new idea on this. I think we should add an initdb option that takes a string to specify the local authentication method: initdb --localauth 'ident' or whatever the user wants. I think this is more flexible and more compact. It would default to 'trust', and the packagers could set it to whatever they want. If their OS supports local ident, they can use that. Also keep in mind you might want some ident map file: initdb --localauth 'ident mymap' so you would need to allow multiple words in the string. --- Magnus Hagander wrote: Here's a version of this patch that includes documentation updates. //Magnus -Original Message- From: Magnus Hagander Sent: den 15 juli 2004 23:02 To: [EMAIL PROTECTED] Subject: [PATCHES] initdb authentication Ok, here is one more try at the initdb default authentication stuff. This one adds the switches --ident and --trust, which will configure pg_hba.conf with ident and trust authentication respectively. If trust authentication is selected, a warning is written to pg_hba.conf. The old switches for password prompt/file still apply. This one makes it mandatory to pick some kind of authentication. If that's not wanted, it's easy to change it to default to trust (which I think is wrong, but we've been through that already..) Oh, and this time, the comments are updated :-) //Magnus Content-Description: initdb_auth.patch [ Attachment, skipping... ] ---(end of broadcast)--- TIP 8: explain analyze is your friend -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] pg_autovacuum integration attempt #2
On Fri, 2004-07-16 at 17:13, Bruce Momjian wrote: Peter Eisentraut wrote: A nitpick on that parameter name: There is not reason to abbreviate autovacuum: there is enough space. And the _enabled is redundant. Agreed. Nitpicks are important too because it makes us so beautiful. :-) :-) I'll make that change. What I am missing at least is what you really mean by the required GUC variables are also set. GUC variables are always set to something (at least after the initialization phase, but you don't get to do anything with GUC before the initialization, obviously). He means he has to have the stats collector enabled along with autovacuum, and he doesn't have a way to effectively test that stats are enabled when enabling autovacuum because the ordering of postgresql.conf variable loads isn't predefined. Exactly. However, I can work around the GUC ordering issue just by having the postmaster check all the required variables before launching autovac. What I wanted to do was have GUC prevent autovacuum = true when the stats collector is not enabled, reguardless of what is in postgresql.conf. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
