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?
