Lists: | pgsql-hackerspgsql-patches |
---|
From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | "Hackers (PostgreSQL)" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | heads up -- subtle change of behavior of new initdb |
Date: | 2003-11-14 05:49:58 |
Message-ID: | 3FB46D06.90100@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers pgsql-patches |
I just noticed tonight that the new initdb introduced a subtle change of
behavior. I use a shell script to automate the process of
- rm old data directory
- mkdir new data directory
- initdb
- load from pgdumpall
Now, that second step is not needed, but as of today it produces an
installation that won't start due to improper permissions on data
Thought it was worth mentioning, or possibly reinstating old behavior.
Joe
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Joe Conway <mail(at)joeconway(dot)com> |
Cc: | "Hackers (PostgreSQL)" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: heads up -- subtle change of behavior of new initdb |
Date: | 2003-11-14 06:02:18 |
Message-ID: | 17410.1068789738@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers pgsql-patches |
Joe Conway <mail(at)joeconway(dot)com> writes:
> I just noticed tonight that the new initdb introduced a subtle change of
> behavior. I use a shell script to automate the process of
> - rm old data directory
> - mkdir new data directory
> - initdb
> - load from pgdumpall
> Now, that second step is not needed, but as of today it produces an
> installation that won't start due to improper permissions on data
That's a bug --- evidently the "fix permissions" path of control is
wrong; can you take a look?
regards, tom lane
From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Hackers (PostgreSQL)" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: heads up -- subtle change of behavior of new initdb |
Date: | 2003-11-14 06:44:58 |
Message-ID: | 3FB479EA.4050604@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers pgsql-patches |
Tom Lane wrote:
> Joe Conway <mail(at)joeconway(dot)com> writes:
>>Now, that second step is not needed, but as of today it produces an
>>installation that won't start due to improper permissions on data
>
> That's a bug --- evidently the "fix permissions" path of control is
> wrong; can you take a look?
Here's a small patch. I think this is all that's needed.
Joe
Attachment | Content-Type | Size |
---|---|---|
initdb-fix.patch | text/plain | 556 bytes |
From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | "Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org>, "Hackers (PostgreSQL)" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] heads up -- subtle change of behavior of new initdb |
Date: | 2003-11-14 06:57:36 |
Message-ID: | 3FB47CE0.8010901@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers pgsql-patches |
darnit!
patch attached.
(Thinks - do we need to worry about suid sgid and sticky bits on data dir?)
andrew
Tom Lane wrote:
>Joe Conway <mail(at)joeconway(dot)com> writes:
>
>
>>I just noticed tonight that the new initdb introduced a subtle change of
>>behavior. I use a shell script to automate the process of
>>- rm old data directory
>>- mkdir new data directory
>>- initdb
>>- load from pgdumpall
>>Now, that second step is not needed, but as of today it produces an
>>installation that won't start due to improper permissions on data
>>
>>
>
>That's a bug --- evidently the "fix permissions" path of control is
>wrong; can you take a look?
>
>
>
>
Attachment | Content-Type | Size |
---|---|---|
initdb.c.permpatch | text/plain | 623 bytes |
From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: heads up -- subtle change of behavior of new initdb |
Date: | 2003-11-14 12:27:51 |
Message-ID: | 87oevfnni0.fsf@stark.dyndns.tv |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers pgsql-patches |
> + if (!chmod(pg_data,0700))
Out of curiosity, what was the rationale for using 0700? I know it was a pain
for me when I had a script to monitor the tmp usage. Surely read access to
privileged users isn't really a problem? I'm thinking more of loosening the
paranoia check elsewhere rather than this default.
Wouldn't at least 0750 be safe? That way putting a user in the postgres group
would grant him access to be able to browse around and read the files in
pg_data.
Actually I should think 02750 would be better so that the group is inherited
by subdirectories.
--
greg
From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Greg Stark <gsstark(at)mit(dot)edu> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: heads up -- subtle change of behavior of new initdb |
Date: | 2003-11-14 12:53:01 |
Message-ID: | Pine.LNX.4.44.0311141352100.3585-100000@peter.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers pgsql-patches |
Greg Stark writes:
> Wouldn't at least 0750 be safe? That way putting a user in the postgres group
> would grant him access to be able to browse around and read the files in
> pg_data.
That assumes that there is a restricted postgres group, which is not
guaranteed.
--
Peter Eisentraut peter_e(at)gmx(dot)net
From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: heads up -- subtle change of behavior of new initdb |
Date: | 2003-11-14 13:08:40 |
Message-ID: | 3FB4D3D8.1090304@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers pgsql-patches |
The shell script said this:
$ECHO_N "fixing permissions on existing directory $PGDATA...
"$ECHO_C
chmod go-rwx "$PGDATA" || exit_nicely
There's no more rationale than that for this patch.
I'm inclined to agree with you, though.
cheers
andrew
Greg Stark wrote:
>>+ if (!chmod(pg_data,0700))
>>
>>
>
>Out of curiosity, what was the rationale for using 0700? I know it was a pain
>for me when I had a script to monitor the tmp usage. Surely read access to
>privileged users isn't really a problem? I'm thinking more of loosening the
>paranoia check elsewhere rather than this default.
>
>Wouldn't at least 0750 be safe? That way putting a user in the postgres group
>would grant him access to be able to browse around and read the files in
>pg_data.
>
>Actually I should think 02750 would be better so that the group is inherited
>by subdirectories.
>
>
>
From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Greg Stark <gsstark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: heads up -- subtle change of behavior of new initdb |
Date: | 2003-11-14 16:10:32 |
Message-ID: | 871xsbnd6v.fsf@stark.dyndns.tv |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers pgsql-patches |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Greg Stark writes:
>
> > Wouldn't at least 0750 be safe? That way putting a user in the postgres group
> > would grant him access to be able to browse around and read the files in
> > pg_data.
>
> That assumes that there is a restricted postgres group, which is not
> guaranteed.
Well the current setup assumes the admin hasn't leaked the root password too.
I'm not suggesting making that the default setup, just loosening the paranoia
check so that if an admin sets the directory to be group readable the database
doesn't refuse to start up.
--
greg
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Greg Stark <gsstark(at)mit(dot)edu> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: heads up -- subtle change of behavior of new initdb |
Date: | 2003-11-14 16:43:38 |
Message-ID: | 26709.1068828218@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers pgsql-patches |
Greg Stark <gsstark(at)mit(dot)edu> writes:
> I'm not suggesting making that the default setup, just loosening the
> paranoia check so that if an admin sets the directory to be group
> readable the database doesn't refuse to start up.
In previous discussions of this point, paranoia was considered desirable.
I don't think the situation has changed.
regards, tom lane
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | "Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org>, "Hackers (PostgreSQL)" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] heads up -- subtle change of behavior of new initdb |
Date: | 2003-11-14 17:21:36 |
Message-ID: | 117.1068830496@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers pgsql-patches |
Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> darnit!
> patch attached.
Applied with correction (you got the return-value check backwards)
and further work to deal reasonably with error conditions occurring
in check_data_dir.
regards, tom lane
From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Postgresql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: heads up -- subtle change of behavior of new initdb |
Date: | 2003-11-14 17:23:21 |
Message-ID: | 3FB50F89.9010004@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers pgsql-patches |
Tom Lane wrote:
>Greg Stark <gsstark(at)mit(dot)edu> writes:
>
>
>>I'm not suggesting making that the default setup, just loosening the
>>paranoia check so that if an admin sets the directory to be group
>>readable the database doesn't refuse to start up.
>>
>>
>
>In previous discussions of this point, paranoia was considered desirable.
>I don't think the situation has changed.
>
>
>
Would it be worth having a command line option to relax the paranoia a
bit, leaving the current paranoia setting as the default? I guess it
would have to be on the command line because IIRC this is checked before
we ever look at the config file.
cheers
andrew
From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | "Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org>, "Hackers (PostgreSQL)" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] heads up -- subtle change of behavior of new initdb |
Date: | 2003-11-14 17:26:34 |
Message-ID: | 200311141726.hAEHQYE28925@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers pgsql-patches |
Patch applied. Thanks.
---------------------------------------------------------------------------
Andrew Dunstan wrote:
>
> darnit!
>
> patch attached.
>
> (Thinks - do we need to worry about suid sgid and sticky bits on data dir?)
>
> andrew
>
> Tom Lane wrote:
>
> >Joe Conway <mail(at)joeconway(dot)com> writes:
> >
> >
> >>I just noticed tonight that the new initdb introduced a subtle change of
> >>behavior. I use a shell script to automate the process of
> >>- rm old data directory
> >>- mkdir new data directory
> >>- initdb
> >>- load from pgdumpall
> >>Now, that second step is not needed, but as of today it produces an
> >>installation that won't start due to improper permissions on data
> >>
> >>
> >
> >That's a bug --- evidently the "fix permissions" path of control is
> >wrong; can you take a look?
> >
> >
> >
> >
> ? .deps
> ? initdb
> Index: initdb.c
> ===================================================================
> RCS file: /projects/cvsroot/pgsql-server/src/bin/initdb/initdb.c,v
> retrieving revision 1.7
> diff -c -w -r1.7 initdb.c
> *** initdb.c 13 Nov 2003 23:46:31 -0000 1.7
> --- initdb.c 14 Nov 2003 06:47:50 -0000
> ***************
> *** 2345,2350 ****
> --- 2345,2359 ----
>
> made_new_pgdata = true;
> }
> + else
> + {
> + printf("fixing permissions on existing directory %s... ",pg_data);
> + fflush(stdout);
> + if (!chmod(pg_data,0700))
> + exit_nicely();
> + else
> + check_ok();
> + }
>
> /* Create required subdirectories */
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, "Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org>, "Hackers (PostgreSQL)" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] heads up -- subtle change of behavior of new |
Date: | 2003-11-14 17:35:08 |
Message-ID: | 200311141735.hAEHZ8Z12784@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers pgsql-patches |
Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> > darnit!
> > patch attached.
>
> Applied with correction (you got the return-value check backwards)
> and further work to deal reasonably with error conditions occurring
> in check_data_dir.
Tom applied it before I could.
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | "Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org>, "Hackers (PostgreSQL)" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] heads up -- subtle change of behavior of |
Date: | 2003-11-14 17:50:25 |
Message-ID: | 3FB515E1.9050604@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers pgsql-patches |
Tom Lane wrote:
>Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>
>
>>darnit!
>>patch attached.
>>
>>
>
>Applied with correction (you got the return-value check backwards)
>and further work to deal reasonably with error conditions occurring
>in check_data_dir.
>
darnit again.
I'm taking a break - my head is swimming with Java, JavaScript, Perl,
HTML and XML/XSL from my real (i.e. paying) work, and context switching
is causing massive mental thrashing.
cheers
andrew