Re: Regrading TODO item alerting pg_hba.conf from SQL
От | Tom Lane |
---|---|
Тема | Re: Regrading TODO item alerting pg_hba.conf from SQL |
Дата | |
Msg-id | 17120.1145202482@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Regrading TODO item alerting pg_hba.conf from SQL (Martijn van Oosterhout <kleptog@svana.org>) |
Ответы |
Re: Regrading TODO item alerting pg_hba.conf from SQL
|
Список | pgsql-hackers |
Martijn van Oosterhout <kleptog@svana.org> writes: >> there is actually no proof of the current order depency is really >> a good idea. Other access lists work without that constraint. > For something that may not be a good idea, it's awfully popular. Didn't we have this entire discussion a month ago? I don't think there would be any objection to adding a database-level CONNECT privilege that's checked inside the database, *after* the existing pg_hba.conf mechanism. That requires no new concepts: we already have databases and privilege bits for them. If the default is to grant CONNECT to PUBLIC then the behavior is backward-compatible, and people can use the privilege, pg_hba.conf, or a combination to control access. (Might be best to call it USAGE so we don't need to create a new reserved word, but that's a minor detail.) Eliminating pg_hba.conf altogether is a much harder sell, because you'd have to prove that you're not giving up any functionality, and quite frankly I don't think you can prove that. (Arguing that people don't need the functionality you can't provide is not going to carry the day.) In any case it would force a lot of relearning on DBAs, and there will be push-back just because of that. I'm also not pleased with adding a bunch of concepts that are not even part of the SQL world (eg, SSL, Unix-domain connections) into GRANT. regards, tom lane
В списке pgsql-hackers по дате отправления: