Re: AW: [HACKERS] Solution to the pg_user passwd problem !?? (c)
| От | Tom I Helbekkmo |
|---|---|
| Тема | Re: AW: [HACKERS] Solution to the pg_user passwd problem !?? (c) |
| Дата | |
| Msg-id | 19980219212950.41630@Hamartun.Priv.NO обсуждение исходный текст |
| Ответ на | Re: AW: [HACKERS] Solution to the pg_user passwd problem !?? (c) (The Hermit Hacker <scrappy@hub.org>) |
| Ответы |
Re: AW: [HACKERS] Solution to the pg_user passwd problem !?? (c)
|
| Список | pgsql-hackers |
[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"
В списке pgsql-hackers по дате отправления: