Re: New pg_pwd patch and stuff

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