Are you working on an initdb option for passwords, so we don't have
pg_user world-unreadable by default?
>
> > What, pg_user is not readable by world anymore? This could be a problem.
>
> It has to be this way, otherwise it would be possible for user to see other
> users' passwords in pg_user. I spoke to you all about this when I first started.
> I was going to make a separate relation (pg_password), but I was convinced not
> to since there is a one to one correlation between users and passwords. At this
> point I sent email to the effect that pg_user could no longer be readable by
> the group 'public'. If it was readable by public, then the passwords would have
> to be encrypted in pg_user. If this is the case, then the frontends will have
> to pass an unencrypted password over the network. Again this degrades the
> security of PostgreSQL.
>
> The real solution to this problem would be to create a pg_privileges relation,
> overhauling the privileges system entirely. Then we could just restrict access
> to the password column of pg_user. However, I would suggest that the entire
> pg_privileges table be cached in shared memory to speed things up. I am unsure
> if the catalog table are cached in shared memory or not (They really should be,
> but then this would probably require some logging to files in case of system
> crash).
>
> In the meantime, there should really be nothing that the average user will need
> from pg_user. The '\d' is the only problem I have encountered thus far, and I
> hope to solve that problem soon. Therefore, if you really, really need something
> from pg_user, then you need to have select privileges given to you explicitly,
> or you could explicitly give them to public. This would, however, give public
> the ability to see user passwords (If you are using, HBA only, then just give
> public the select over pg_user).
>
> Todd A. Brandys
> brandys@eng3.hep.uiuc.edu
>
>
--
Bruce Momjian
maillist@candle.pha.pa.us
