Re: AW: [HACKERS] Solution to the pg_user passwd problem !?? (c)
От | jwieck@debis.com (Jan Wieck) |
---|---|
Тема | Re: AW: [HACKERS] Solution to the pg_user passwd problem !?? (c) |
Дата | |
Msg-id | m0y5Ylb-000BFRC@orion.SAPserv.Hamburg.dsh.de обсуждение исходный текст |
Ответ на | 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 ? > > > > > > * Teardrops keep falling on my head ... * :-( > > > > It was brilliant, even if it doesn't fully solve the problem. > > It solves enough of the problem for v6.3's release...I still think > its important to get it so that a 'grant select' can be imposed on a view > that looks at a table that as a 'revoke all' on it...this would fix the > problem cleanly, and completely... > > Then you could do a 'copy all_users to stdout;' vs a 'copy > pg_users to stdout;' Copy on a view doesn't return anything! I think it's in the coding of the copy command - as far as I remember the copy directly accesses the table bypassing the rule system. But the table underlying the view is empty and the values are faked into the view via the rewrite rule system. The 'grant select' on views is a IMHO urgent required feature. I'll take a look on the code checking permissions and the rewrite system. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #======================================== jwieck@debis.com (Jan Wieck) #
В списке pgsql-hackers по дате отправления: