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