Thread: AW: [HACKERS] Solution to the pg_user passwd problem !?? (c)
The command copy pg_user to stdout; will also show the cleartext password and I think it is hard to do a rewrite here, since this would also affect the pg_dump ? * Teardrops keep falling on my head ... * :-( Andreas > ---------- > Von: Jan Wieck[SMTP:jwieck@debis.com] > Antwort an: Jan Wieck > Gesendet: Donnerstag, 19. Februar 1998 15:53 > An: Zeugswetter Andreas SARZ > Cc: pgsql-hackers@hub.org > Betreff: Re: [HACKERS] Solution to the pg_user passwd problem !?? (c) > > > > > Hi all, > > > > What about: > > grant select on pg_user to public; > > create rule pg_user_hide_pw as on > > select to pg_user.passwd > > do instead select '********' as passwd; > > > > Then if I do: > > select * from pg_user; > > usename |usesysid|usecreatedb|usetrace|usesuper|usecatupd|passwd > |valuntil > > > --------+--------+-----------+--------+--------+---------+--------+------- > -- > > ------------------- > > postgres| 6|t |t |t |t |********|Sat > Jan > > 31 07:00:00 2037 NFT > > zeus | 60|t |t |f |t |********| > > (2 rows) > > > > Also the \d works for all users ! > > > > Only "disadvantage" is that noone can read passwd without first dropping > the > > rule pg_user_hide_pw, > > I consider this a feature though ;-) > > > > Since the userauthentication bypasses the rewrite mechanism the logins, > > alter user .. and others do work ! > > > > Can all of you try to crack this ? > > Cracked! > > create table get_passwds (usename name, passwd text); > insert into get_passwds select usename, passwd from pg_user; > select * from get_passwds; > usename|passwd > -------+------ > pgsql | > wieck |test > (2 rows) > > > > Sorry, Jan > > -- > > #======================================================================# > # It's easier to get forgiveness for being wrong than for being right. # > # Let's break this rule - forgive me. # > #======================================== jwieck@debis.com (Jan Wieck) # > > >
> > The command > copy pg_user to stdout; > > will also show the cleartext password and I think it is hard to do a rewrite > here, > since this would also affect the pg_dump ? > > * Teardrops keep falling on my head ... * :-( It was brilliant, even if it doesn't fully solve the problem. -- Bruce Momjian maillist@candle.pha.pa.us
On Thu, 19 Feb 1998, Bruce Momjian wrote:
> >
> > The command
> > copy pg_user to stdout;
> >
> > will also show the cleartext password and I think it is hard to do a rewrite
> > here,
> > since this would also affect the pg_dump ?
> >
> > * Teardrops keep falling on my head ... * :-(
>
> It was brilliant, even if it doesn't fully solve the problem.
It solves enough of the problem for v6.3's release...I still think
its important to get it so that a 'grant select' can be imposed on a view
that looks at a table that as a 'revoke all' on it...this would fix the
problem cleanly, and completely...
Then you could do a 'copy all_users to stdout;' vs a 'copy
pg_users to stdout;'
Re: AW: [HACKERS] Solution to the pg_user passwd problem !?? (c)
From
jwieck@debis.com (Jan Wieck)
Date:
>
> >
> > The command
> > copy pg_user to stdout;
> >
> > will also show the cleartext password and I think it is hard to do a rewrite
> > here,
> > since this would also affect the pg_dump ?
> >
> > * Teardrops keep falling on my head ... * :-(
>
> It was brilliant, even if it doesn't fully solve the problem.
>
> --
> Bruce Momjian
> maillist@candle.pha.pa.us
>
Not only that it was brilliant - as stated in my last post it
also showed that there is a bug in the rewrite system that
must get fixed so we can use views in INSERT...SELECT!
Please add this to the TODO.
For the pg_user permission problem I can think about another
solution. It's a feature still on my personal wishlist -
setuid views.
Until later, Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #
Re: AW: [HACKERS] Solution to the pg_user passwd problem !?? (c)
From
jwieck@debis.com (Jan Wieck)
Date:
>
> On Thu, 19 Feb 1998, Bruce Momjian wrote:
>
> > >
> > > The command
> > > copy pg_user to stdout;
> > >
> > > will also show the cleartext password and I think it is hard to do a rewrite
> > > here,
> > > since this would also affect the pg_dump ?
> > >
> > > * Teardrops keep falling on my head ... * :-(
> >
> > It was brilliant, even if it doesn't fully solve the problem.
>
> It solves enough of the problem for v6.3's release...I still think
> its important to get it so that a 'grant select' can be imposed on a view
> that looks at a table that as a 'revoke all' on it...this would fix the
> problem cleanly, and completely...
>
> Then you could do a 'copy all_users to stdout;' vs a 'copy
> pg_users to stdout;'
Copy on a view doesn't return anything! I think it's in the
coding of the copy command - as far as I remember the copy
directly accesses the table bypassing the rule system. But
the table underlying the view is empty and the values are
faked into the view via the rewrite rule system.
The 'grant select' on views is a IMHO urgent required
feature. I'll take a look on the code checking permissions
and the rewrite system.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #
> > > > > > > > > The command > > > copy pg_user to stdout; > > > > > > will also show the cleartext password and I think it is hard to do a rewrite > > > here, > > > since this would also affect the pg_dump ? > > > > > > * Teardrops keep falling on my head ... * :-( > > > > It was brilliant, even if it doesn't fully solve the problem. > > > > -- > > Bruce Momjian > > maillist@candle.pha.pa.us > > > > Not only that it was brilliant - as stated in my last post it > also showed that there is a bug in the rewrite system that > must get fixed so we can use views in INSERT...SELECT! > Please add this to the TODO. > > For the pg_user permission problem I can think about another > solution. It's a feature still on my personal wishlist - > setuid views. Added to TODO: * Allow INSERT INTO ... SELECT ... FROM view to work We already had: * Allow VIEW permissions to be set separately from the underlying tables -- Bruce Momjian maillist@candle.pha.pa.us
> > The command > copy pg_user to stdout; > > will also show the cleartext password and I think it is hard to do a rewrite > here, > since this would also affect the pg_dump ? OK, I have committed code that removes the REVOKE from initdb, and does not allow them to do any adding or altering of users if there is a password involved AND the ACL for pg_user is null. It prints a nice message telling them they need to issue the REVOKE command so normal users can't read the passwords. If they use user passwords psql \d does fail if you do this. Do we want to duplicate the query without the pg_user reference if the \d query fails? -- Bruce Momjian maillist@candle.pha.pa.us
On Thu, 19 Feb 1998, Bruce Momjian wrote:
> >
> > The command
> > copy pg_user to stdout;
> >
> > will also show the cleartext password and I think it is hard to do a rewrite
> > here,
> > since this would also affect the pg_dump ?
>
> OK, I have committed code that removes the REVOKE from initdb, and does
> not allow them to do any adding or altering of users if there is a
> password involved AND the ACL for pg_user is null. It prints a nice
> message telling them they need to issue the REVOKE command so normal
> users can't read the passwords.
I put the REVOKE back in, with the appropriate rule rewrite...I've
tried it here and it works cleanly, and just masks out the passwd
entry...doesn't compensate for the 'copy' problem, but its better then
expecting the admin to go do the revoke on his own :(
Re: AW: [HACKERS] Solution to the pg_user passwd problem !?? (c)
From
jwieck@debis.com (Jan Wieck)
Date:
I wrote:
> The 'grant select' on views is a IMHO urgent required
> feature. I'll take a look on the code checking permissions
> and the rewrite system.
Interesting - first of all an unprivileged user cannot create
any view "pg_rewrite: Permission denied". I think this is
absolutely wrong.
Anyway - if we add a flag to the rangetable entry that tells
the executor in ExecCheckPerms() if this rte came from the
rewriting due to a view or not, it can skip the permission
check on that and the tests will pass.
But then we'll run into a little security hole problem. If
the permissions only rely on access to the view, the view
owner (or public as long as ACL_WORLD_DEFAULT contains
ACL_RD) can select throug the view. So we must check on view
creation that the creator of the view has proper permissions
to what the view selects. And in addition if not all objects
the view selects are granted to public, we should
automagically revoke public from the view so the creator must
explicitly grant access to the view.
Anything forgotten?
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #
> > On Thu, 19 Feb 1998, Bruce Momjian wrote: > > > > > > > The command > > > copy pg_user to stdout; > > > > > > will also show the cleartext password and I think it is hard to do a rewrite > > > here, > > > since this would also affect the pg_dump ? > > > > OK, I have committed code that removes the REVOKE from initdb, and does > > not allow them to do any adding or altering of users if there is a > > password involved AND the ACL for pg_user is null. It prints a nice > > message telling them they need to issue the REVOKE command so normal > > users can't read the passwords. > > I put the REVOKE back in, with the appropriate rule rewrite...I've > tried it here and it works cleanly, and just masks out the passwd > entry...doesn't compensate for the 'copy' problem, but its better then > expecting the admin to go do the revoke on his own :( Sorry, don't like it. First, by doing a REVOKE ALL and GRANT SELECT, you have the same permissions as default, except the pg_user permissions are not null and therefore my check allows it. Second, if COPY works, then passwords are not secure, and there is no reason for the feature. Either a feature is secure and valuable, or unsecure and worse then unvaluable because people think it is secure, and it is not. -- Bruce Momjian maillist@candle.pha.pa.us
> > > I wrote: > > The 'grant select' on views is a IMHO urgent required > > feature. I'll take a look on the code checking permissions > > and the rewrite system. > > Interesting - first of all an unprivileged user cannot create > any view "pg_rewrite: Permission denied". I think this is > absolutely wrong. > > Anyway - if we add a flag to the rangetable entry that tells > the executor in ExecCheckPerms() if this rte came from the > rewriting due to a view or not, it can skip the permission > check on that and the tests will pass. > > But then we'll run into a little security hole problem. If > the permissions only rely on access to the view, the view > owner (or public as long as ACL_WORLD_DEFAULT contains > ACL_RD) can select throug the view. So we must check on view > creation that the creator of the view has proper permissions > to what the view selects. And in addition if not all objects > the view selects are granted to public, we should > automagically revoke public from the view so the creator must > explicitly grant access to the view. > > Anything forgotten? No, I think these are the valid issues. -- Bruce Momjian maillist@candle.pha.pa.us
On Thu, 19 Feb 1998, Bruce Momjian wrote:
> >
> > On Thu, 19 Feb 1998, Bruce Momjian wrote:
> >
> > > >
> > > > The command
> > > > copy pg_user to stdout;
> > > >
> > > > will also show the cleartext password and I think it is hard to do a rewrite
> > > > here,
> > > > since this would also affect the pg_dump ?
> > >
> > > OK, I have committed code that removes the REVOKE from initdb, and does
> > > not allow them to do any adding or altering of users if there is a
> > > password involved AND the ACL for pg_user is null. It prints a nice
> > > message telling them they need to issue the REVOKE command so normal
> > > users can't read the passwords.
> >
> > I put the REVOKE back in, with the appropriate rule rewrite...I've
> > tried it here and it works cleanly, and just masks out the passwd
> > entry...doesn't compensate for the 'copy' problem, but its better then
> > expecting the admin to go do the revoke on his own :(
>
> Sorry, don't like it. First, by doing a REVOKE ALL and GRANT SELECT,
> you have the same permissions as default, except the pg_user permissions
> are not null and therefore my check allows it.
>
> Second, if COPY works, then passwords are not secure, and there is no
> reason for the feature. Either a feature is secure and valuable, or
> unsecure and worse then unvaluable because people think it is secure,
> and it is not.
Just curious, but why don't the copy command fall under the same
grant/revoke restrictions in the first place? It sounds to me like we are
backing off of the problem instead of addressing it...
The problem being that it appears that 'copy' overrides/ignores
the rewrite rules, which kind of invalidates having them, doesn't it?
What would it take to have copy follow them as select does?
Re: AW: [HACKERS] Solution to the pg_user passwd problem !?? (c)
From
jwieck@debis.com (Jan Wieck)
Date:
> Just curious, but why don't the copy command fall under the same
> grant/revoke restrictions in the first place? It sounds to me like we are
> backing off of the problem instead of addressing it...
>
> The problem being that it appears that 'copy' overrides/ignores
> the rewrite rules, which kind of invalidates having them, doesn't it?
> What would it take to have copy follow them as select does?
Copy does a heap scan by itself. Doesn't care about rules.
Instead copy must do a SELECT internal. Don't know if that
is really what copy should do.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #
> Just curious, but why don't the copy command fall under the same > grant/revoke restrictions in the first place? It sounds to me like we are > backing off of the problem instead of addressing it... grant/revoke works for copy. > > The problem being that it appears that 'copy' overrides/ignores > the rewrite rules, which kind of invalidates having them, doesn't it? > What would it take to have copy follow them as select does? Hard, because COPY does not do joins and does not go through the optimizer and executor. It dumps single tables. Tough to yank that through rewrite. -- Bruce Momjian maillist@candle.pha.pa.us
On Thu, 19 Feb 1998, Bruce Momjian wrote:
> > Just curious, but why don't the copy command fall under the same
> > grant/revoke restrictions in the first place? It sounds to me like we are
> > backing off of the problem instead of addressing it...
>
> grant/revoke works for copy.
Ah, okay, so when we have it setup so that a view overrides the
'grant' of a select, then we're fine?
> > On Thu, 19 Feb 1998, Bruce Momjian wrote: > > > > Just curious, but why don't the copy command fall under the same > > > grant/revoke restrictions in the first place? It sounds to me like we are > > > backing off of the problem instead of addressing it... > > > > grant/revoke works for copy. > > Ah, okay, so when we have it setup so that a view overrides the > 'grant' of a select, then we're fine? Yep, but can we do that in nine days, and be sure it is tested? -- Bruce Momjian maillist@candle.pha.pa.us
On Thu, 19 Feb 1998, Bruce Momjian wrote:
> >
> > On Thu, 19 Feb 1998, Bruce Momjian wrote:
> >
> > > > Just curious, but why don't the copy command fall under the same
> > > > grant/revoke restrictions in the first place? It sounds to me like we are
> > > > backing off of the problem instead of addressing it...
> > >
> > > grant/revoke works for copy.
> >
> > Ah, okay, so when we have it setup so that a view overrides the
> > 'grant' of a select, then we're fine?
>
> Yep, but can we do that in nine days, and be sure it is tested?
I don't think so...but I'rather have the obviuos "select * from
pg_user" closed off, and the more obscure "copy pg_user to stdout" still
there then have both wide open...its a half measure, but its better then
no measure...
Re: AW: [HACKERS] Solution to the pg_user passwd problem !?? (c)
From
jwieck@debis.com (Jan Wieck)
Date:
>
> >
> > On Thu, 19 Feb 1998, Bruce Momjian wrote:
> >
> > > > Just curious, but why don't the copy command fall under the same
> > > > grant/revoke restrictions in the first place? It sounds to me like we are
> > > > backing off of the problem instead of addressing it...
> > >
> > > grant/revoke works for copy.
> >
> > Ah, okay, so when we have it setup so that a view overrides the
> > 'grant' of a select, then we're fine?
>
> Yep, but can we do that in nine days, and be sure it is tested?
Don't think so - not really hard tested.
>
> --
> Bruce Momjian
> maillist@candle.pha.pa.us
>
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #
> > On Thu, 19 Feb 1998, Bruce Momjian wrote: > > > > > > > On Thu, 19 Feb 1998, Bruce Momjian wrote: > > > > > > > > Just curious, but why don't the copy command fall under the same > > > > > grant/revoke restrictions in the first place? It sounds to me like we are > > > > > backing off of the problem instead of addressing it... > > > > > > > > grant/revoke works for copy. > > > > > > Ah, okay, so when we have it setup so that a view overrides the > > > 'grant' of a select, then we're fine? > > > > Yep, but can we do that in nine days, and be sure it is tested? > > I don't think so...but I'rather have the obviuos "select * from > pg_user" closed off, and the more obscure "copy pg_user to stdout" still > there then have both wide open...its a half measure, but its better then > no measure... But it is not secure. Why have passwords then? -- Bruce Momjian maillist@candle.pha.pa.us
> > > > > > > > > On Thu, 19 Feb 1998, Bruce Momjian wrote: > > > > > > > > Just curious, but why don't the copy command fall under the same > > > > > grant/revoke restrictions in the first place? It sounds to me like we are > > > > > backing off of the problem instead of addressing it... > > > > > > > > grant/revoke works for copy. > > > > > > Ah, okay, so when we have it setup so that a view overrides the > > > 'grant' of a select, then we're fine? > > > > Yep, but can we do that in nine days, and be sure it is tested? > > Don't think so - not really hard tested. If you think you can get it in with light testing by the beta people, Marc might bite on it. -- Bruce Momjian maillist@candle.pha.pa.us
On Thu, 19 Feb 1998, Bruce Momjian wrote:
> >
> > On Thu, 19 Feb 1998, Bruce Momjian wrote:
> >
> > > >
> > > > On Thu, 19 Feb 1998, Bruce Momjian wrote:
> > > >
> > > > > > Just curious, but why don't the copy command fall under the same
> > > > > > grant/revoke restrictions in the first place? It sounds to me like we are
> > > > > > backing off of the problem instead of addressing it...
> > > > >
> > > > > grant/revoke works for copy.
> > > >
> > > > Ah, okay, so when we have it setup so that a view overrides the
> > > > 'grant' of a select, then we're fine?
> > >
> > > Yep, but can we do that in nine days, and be sure it is tested?
> >
> > I don't think so...but I'rather have the obviuos "select * from
> > pg_user" closed off, and the more obscure "copy pg_user to stdout" still
> > there then have both wide open...its a half measure, but its better then
> > no measure...
>
> But it is not secure. Why have passwords then?
passswords had to get in there at *some* point...they are there
now, now we have to extend the security to the next level. Better to move
forward 1 step at a time. If we remove the REVOKE altogether, the
passwords are still there, but there is *0* security instead of 50%
security...
So, I think we should leave the REVOKE/GRANT in initdb, and work
at having grant/revoke work on a view (such that a view overrides the
revoke of all on pg_user) so that it is appliable *after* v6.3 is
released, and available as (if possible) a patch for just after...
We aren't hurting anything by leaving the REVOKE/GRANT in place,
but I think we are if we remove it and just leave it wide open...
On Thu, 19 Feb 1998, Bruce Momjian wrote:
> >
> > >
> > > >
> > > > On Thu, 19 Feb 1998, Bruce Momjian wrote:
> > > >
> > > > > > Just curious, but why don't the copy command fall under the same
> > > > > > grant/revoke restrictions in the first place? It sounds to me like we are
> > > > > > backing off of the problem instead of addressing it...
> > > > >
> > > > > grant/revoke works for copy.
> > > >
> > > > Ah, okay, so when we have it setup so that a view overrides the
> > > > 'grant' of a select, then we're fine?
> > >
> > > Yep, but can we do that in nine days, and be sure it is tested?
> >
> > Don't think so - not really hard tested.
>
> If you think you can get it in with light testing by the beta people,
> Marc might bite on it.
There is nothing wrong with doing what we did last time...we have,
what, 7 post-release patches for v6.2.1?
> passswords had to get in there at *some* point...they are there > now, now we have to extend the security to the next level. Better to move > forward 1 step at a time. If we remove the REVOKE altogether, the > passwords are still there, but there is *0* security instead of 50% > security... If we remove the REVOKE, then people will not use passwords by mistake, thinking they are secure. To use them, they have to issue a REVOKE, and then they are secure. What am I missing here? > > So, I think we should leave the REVOKE/GRANT in initdb, and work > at having grant/revoke work on a view (such that a view overrides the > revoke of all on pg_user) so that it is appliable *after* v6.3 is > released, and available as (if possible) a patch for just after... > > We aren't hurting anything by leaving the REVOKE/GRANT in place, > but I think we are if we remove it and just leave it wide open... Again, am I missing something? -- Bruce Momjian maillist@candle.pha.pa.us
Re: AW: [HACKERS] Solution to the pg_user passwd problem !?? (c)
From
Robson Paniago de Miranda
Date:
Bruce Momjian wrote:
>
> > > But it is not secure. Why have passwords then?
> > >
> > I think is better have the encrypted passwords and the salt in pg_user.
> > I don't know if this will be bing a security hole :(
> >
>
> If we do this, then what does the frontend pass us?
>
> --
> Bruce Momjian
> maillist@candle.pha.pa.us
I was thinking in the backend pass the salt stored in pg_user to the
frontend, but doing that is (almost) the same as having the password
stored in clear text. It was a bad idea :(
Robson.
Re: AW: [HACKERS] Solution to the pg_user passwd problem !?? (c)
From
jwieck@debis.com (Jan Wieck)
Date:
Bruce said:
> > > > Ah, okay, so when we have it setup so that a view overrides the
> > > > 'grant' of a select, then we're fine?
> > >
> > > Yep, but can we do that in nine days, and be sure it is tested?
> >
> > Don't think so - not really hard tested.
>
> If you think you can get it in with light testing by the beta people,
> Marc might bite on it.
So I'll give it a try...
Hacking, Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #
[Marc] > I don't think so...but I'rather have the obviuos "select * from > pg_user" closed off, and the more obscure "copy pg_user to stdout" still > there then have both wide open...its a half measure, but its better then > no measure... [Bruce] > But it is not secure. Why have passwords then? [Marc] > passswords had to get in there at *some* point...they are there > now, now we have to extend the security to the next level. Better to move > forward 1 step at a time. If we remove the REVOKE altogether, the > passwords are still there, but there is *0* security instead of 50% > security... Wrong. It's still *0* security, but with the illusion of working security in the eyes of anyone who doesn't know better -- and you're trying to keep them from knowing better. If you go this way, cases *will* occur where people think their data secure, and then someone gains access to it who shouldn't. Security by obscurity never was, and never will be a good idea. Leave wide open looking wide open, and document it. Say something like "This release has a password field in the pg_user table, but it isn't actually useful as a security measure. It's there because we intend to use it in a secure manner in future. Meanwhile, a secure installation of the current version can be achieved by ...". -tih -- Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"
> > Bruce said: > > > > > Ah, okay, so when we have it setup so that a view overrides the > > > > > 'grant' of a select, then we're fine? > > > > > > > > Yep, but can we do that in nine days, and be sure it is tested? > > > > > > Don't think so - not really hard tested. > > > > If you think you can get it in with light testing by the beta people, > > Marc might bite on it. > > So I'll give it a try... I have been hoping to get you back into the rewrite system so we can get a feeling of what does and doesn't work properly there. Here is a good excuse. I did some work on it with aggregates and subselects, and cleaned up some stuff. -- Bruce Momjian maillist@candle.pha.pa.us
On Thu, 19 Feb 1998, Tom I Helbekkmo wrote:
> [Marc]
>
> > I don't think so...but I'rather have the obviuos "select * from
> > pg_user" closed off, and the more obscure "copy pg_user to stdout" still
> > there then have both wide open...its a half measure, but its better then
> > no measure...
>
> [Bruce]
>
> > But it is not secure. Why have passwords then?
>
> [Marc]
>
> > passswords had to get in there at *some* point...they are there
> > now, now we have to extend the security to the next level. Better to move
> > forward 1 step at a time. If we remove the REVOKE altogether, the
> > passwords are still there, but there is *0* security instead of 50%
> > security...
>
> Wrong. It's still *0* security, but with the illusion of working
> security in the eyes of anyone who doesn't know better -- and you're
> trying to keep them from knowing better. If you go this way, cases
> *will* occur where people think their data secure, and then someone
> gains access to it who shouldn't. Security by obscurity never was,
> and never will be a good idea.
>
> Leave wide open looking wide open, and document it. Say something
> like "This release has a password field in the pg_user table, but it
> isn't actually useful as a security measure. It's there because we
> intend to use it in a secure manner in future. Meanwhile, a secure
> installation of the current version can be achieved by ...".
I concede the argument...you guys win...*groan*
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> > Leave wide open looking wide open, and document it. Say something > > like "This release has a password field in the pg_user table, but it > > isn't actually useful as a security measure. It's there because we > > intend to use it in a secure manner in future. Meanwhile, a secure > > installation of the current version can be achieved by ...". > > I concede the argument...you guys win...*groan* OK, back out those patches, nice and slowly. Keep your hands where I can see them. :-) -- Bruce Momjian maillist@candle.pha.pa.us
On Thu, 19 Feb 1998, Bruce Momjian wrote:
> > > Leave wide open looking wide open, and document it. Say something
> > > like "This release has a password field in the pg_user table, but it
> > > isn't actually useful as a security measure. It's there because we
> > > intend to use it in a secure manner in future. Meanwhile, a secure
> > > installation of the current version can be achieved by ...".
> >
> > I concede the argument...you guys win...*groan*
>
> OK, back out those patches, nice and slowly. Keep your hands where I
> can see them. :-)
*rofl* ... its done now :)
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org