Re: AW: [HACKERS] Solution to the pg_user passwd problem !?? (c)
От | Bruce Momjian |
---|---|
Тема | Re: AW: [HACKERS] Solution to the pg_user passwd problem !?? (c) |
Дата | |
Msg-id | 199802191820.NAA10354@candle.pha.pa.us обсуждение исходный текст |
Ответ на | 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 |
> > 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
В списке pgsql-hackers по дате отправления: