Horton

Thread

  1. AW: [HACKERS] Solution to the pg_user passwd problem !?? (c)

    Zeugswetter Andreas <andreas.zeugswetter@telecom.at> — 1998-02-19T15:08:41Z

    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) #
> 
> 
>

  2. Re: AW: [HACKERS] Solution to the pg_user passwd problem !?? (c)

    Bruce Momjian <maillist@candle.pha.pa.us> — 1998-02-19T15:15:35Z

    > 
> 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

  3. Re: AW: [HACKERS] Solution to the pg_user passwd problem !?? (c)

    Marc G. Fournier <scrappy@hub.org> — 1998-02-19T15:59:45Z

    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;'

  4. Re: AW: [HACKERS] Solution to the pg_user passwd problem !?? (c)

    Jan Wieck <jwieck@debis.com> — 1998-02-19T16:06:45Z

    >
> >
> > 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) #

  5. Re: AW: [HACKERS] Solution to the pg_user passwd problem !?? (c)

    Jan Wieck <jwieck@debis.com> — 1998-02-19T16:24:06Z

    >
> 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) #

  6. Re: AW: [HACKERS] Solution to the pg_user passwd problem !?? (c)

    Bruce Momjian <maillist@candle.pha.pa.us> — 1998-02-19T16:31:26Z

    > 
> >
> > >
> > > 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

  7. Re: AW: [HACKERS] Solution to the pg_user passwd problem !?? (c)

    Bruce Momjian <maillist@candle.pha.pa.us> — 1998-02-19T17:19:59Z

    > 
> 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

  8. Re: AW: [HACKERS] Solution to the pg_user passwd problem !?? (c)

    Marc G. Fournier <scrappy@hub.org> — 1998-02-19T17:29:08Z

    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 :(

  9. Re: AW: [HACKERS] Solution to the pg_user passwd problem !?? (c)

    Jan Wieck <jwieck@debis.com> — 1998-02-19T18:02:26Z

    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) #

  10. Re: AW: [HACKERS] Solution to the pg_user passwd problem !?? (c)

    Bruce Momjian <maillist@candle.pha.pa.us> — 1998-02-19T18:17:49Z

    > 
> 
> 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

  11. Re: AW: [HACKERS] Solution to the pg_user passwd problem !?? (c)

    Bruce Momjian <maillist@candle.pha.pa.us> — 1998-02-19T18:20:06Z

    > 
> 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

  12. Re: AW: [HACKERS] Solution to the pg_user passwd problem !?? (c)

    Marc G. Fournier <scrappy@hub.org> — 1998-02-19T18:36:03Z

    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?

  13. Re: AW: [HACKERS] Solution to the pg_user passwd problem !?? (c)

    Jan Wieck <jwieck@debis.com> — 1998-02-19T19:02:23Z

    > 	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) #

  14. Re: AW: [HACKERS] Solution to the pg_user passwd problem !?? (c)

    Bruce Momjian <maillist@candle.pha.pa.us> — 1998-02-19T19:13:30Z

    > 	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

  15. Re: AW: [HACKERS] Solution to the pg_user passwd problem !?? (c)

    Marc G. Fournier <scrappy@hub.org> — 1998-02-19T19:21:45Z

    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?

  16. Re: AW: [HACKERS] Solution to the pg_user passwd problem !?? (c)

    Bruce Momjian <maillist@candle.pha.pa.us> — 1998-02-19T19:26:03Z

    > 
> 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

  17. Re: AW: [HACKERS] Solution to the pg_user passwd problem !?? (c)

    Marc G. Fournier <scrappy@hub.org> — 1998-02-19T19:30:54Z

    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...

  18. Re: AW: [HACKERS] Solution to the pg_user passwd problem !?? (c)

    Jan Wieck <jwieck@debis.com> — 1998-02-19T19:45:46Z

    > 
> > 
> > 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) #

  19. Re: AW: [HACKERS] Solution to the pg_user passwd problem !?? (c)

    Bruce Momjian <maillist@candle.pha.pa.us> — 1998-02-19T19:46:08Z

    > 
> 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

  20. Re: AW: [HACKERS] Solution to the pg_user passwd problem !?? (c)

    Bruce Momjian <maillist@candle.pha.pa.us> — 1998-02-19T19:47:33Z

    > 
> > 
> > > 
> > > 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

  21. Re: AW: [HACKERS] Solution to the pg_user passwd problem !?? (c)

    Marc G. Fournier <scrappy@hub.org> — 1998-02-19T20:01:29Z

    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...

  22. Re: AW: [HACKERS] Solution to the pg_user passwd problem !?? (c)

    Marc G. Fournier <scrappy@hub.org> — 1998-02-19T20:04:20Z

    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?

  23. Re: AW: [HACKERS] Solution to the pg_user passwd problem !?? (c)

    Bruce Momjian <maillist@candle.pha.pa.us> — 1998-02-19T20:13:12Z

    > 	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

  24. Re: AW: [HACKERS] Solution to the pg_user passwd problem !?? (c)

    Tom Ivar Helbekkmo <tih@hamartun.priv.no> — 1998-02-19T20:29:50Z

    [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"

  25. Re: AW: [HACKERS] Solution to the pg_user passwd problem !?? (c)

    Jan Wieck <jwieck@debis.com> — 1998-02-19T21:27:15Z

    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) #

  26. Re: AW: [HACKERS] Solution to the pg_user passwd problem !?? (c)

    Bruce Momjian <maillist@candle.pha.pa.us> — 1998-02-19T21:35:59Z

    > 
> 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

  27. Re: AW: [HACKERS] Solution to the pg_user passwd problem !?? (c)

    Marc G. Fournier <scrappy@hub.org> — 1998-02-19T23:08:39Z

    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

  28. Re: AW: [HACKERS] Solution to the pg_user passwd problem !?? (c)

    Bruce Momjian <maillist@candle.pha.pa.us> — 1998-02-19T23:23:08Z

    > > 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

  29. Re: AW: [HACKERS] Solution to the pg_user passwd problem !?? (c)

    Marc G. Fournier <scrappy@hub.org> — 1998-02-20T01:44:08Z

    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