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