Re: [HACKERS] Re: New pg_pwd patch and stuff

From: todd brandys <brandys(at)eng3(dot)hep(dot)uiuc(dot)edu>
To: maillist(at)candle(dot)pha(dot)pa(dot)us
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] Re: New pg_pwd patch and stuff
Date: 1998-01-18 21:29:50
Message-ID: 199801182129.AA01155@eng3.hep.uiuc.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Well, I can create the table quite easily. The issue is what type of
> flack we will get by haveing pg_user non-readable, and removing the user

What if we were to put the pg_user accessibility to the admin setting up
PostgreSQL (at least until pg_privileges could become a reality.). If you
look in dbinit--toward the end of the script--I run a SQL command to revoke
all privileges from public on the pg_user table. If you are not going to
use the pg_pwd scheme for authentication, then you don't need to run this
command. All we need do for now is print out a little message saying that if
you use HBA or Kerberos, then say No to blocking the PUBLIC from accessing
pg_user. We also say that if you choose to block access to pg_user, these
are the consequences. When a better privileges method is developed this
question in the dbinit script can be eliminated.

I myself would choose to block access to the pg_user relation. Others may not
want it this way. Using the above scenario, the user would have an informed
choice that would be taken care of at initialization.

Todd A. Brandys
brandys(at)eng3(dot)hep(dot)uiuc(dot)edu

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message todd brandys 1998-01-18 21:47:30 Re: [HACKERS] Re: New pg_pwd patch and stuff
Previous Message Bruce Momjian 1998-01-18 19:33:54 Re: [HACKERS] PSQL man page patch