Re: Disabling trust/ident authentication configure option
От | Stephen Frost |
---|---|
Тема | Re: Disabling trust/ident authentication configure option |
Дата | |
Msg-id | 20150520194223.GM26667@tamriel.snowman.net обсуждение исходный текст |
Ответ на | Re: Disabling trust/ident authentication configure option (Josh Berkus <josh@agliodbs.com>) |
Ответы |
Re: Disabling trust/ident authentication configure option
(Tom Lane <tgl@sss.pgh.pa.us>)
Re: Disabling trust/ident authentication configure option (Andres Freund <andres@anarazel.de>) |
Список | pgsql-hackers |
* Josh Berkus (josh@agliodbs.com) wrote: > On 05/20/2015 11:10 AM, Tom Lane wrote: > > Alvaro Herrera <alvherre@2ndquadrant.com> writes: > >> The proposal here is to have a configure argument that disables > >> arbitrary auth mechanisms. How is that specific to a particular > >> environment? > > > > I think Josh's question is whether the feature is actually useful to > > a large class of users. > > > > One reason why it would not be, if it's a build-time decision, > > is that it's quite unlikely that any popular packagers would build > > that way. So this would only be applicable to custom-built binaries, > > which is a pretty small class of users to begin with. > > Precisely. I do not agree with the 'quite unlikely' characterization. We would need to make a case to them as to why there are better options than having 'trust' be supported, but that only makes sense once there *are*. We know there are reasons we need it today and there's not much point having this discussion until those have been addressed. > So the first thing to establish is "other than Volker himself, who are > we helping here?" I don't agree with this either. Providing a "bypass all authentication" configuration option really isn't a good thing. Why don't packagers use our default pg_hba.conf? Because it only makes sense in a development type of environment. I'd argue the same is true for 'trust'. > The second major issue I have is that it's an anti-security feature. > That is, it ignores the several ways in which someone with superuser > access can bypass the lack of an auth mechanism, while giving anyone who > installs the option a false sense of safety. Ineffective security > measures lead to worse security holes than being aware that you're at risk. I don't believe this is correct. Your definition of an anti-security feature is fine, but I don't agree with the assumption that people will feel secure because 'trust' isn't compiled in. Most users are unlikely to notice it's gone and the argument you're making here is that the users who will be upset that it's no longer available are all knowledgable enough to realize when it's valid to use. I seriously doubt that's the case and throwing a big warning in front of them saying "trust is no longer built-in because it's a big glaring security hole, please use another mechanism" would hopefully get them to understand why it was an issue, why it shouldn't be used, and what options are available and what their tradeoffs are. I still don't believe there's much point in the discussion until there are viable alternatives for the use-cases where we really need to be able to just get into PG and get data out quickly in the face of corruption, but I wanted to share my disagreement regarding the assumption that packagers would never consider disabling 'trust'. Thanks! Stephen
В списке pgsql-hackers по дате отправления:
Следующее
От: Alvaro HerreraДата:
Сообщение: Re: RFC: Non-user-resettable SET SESSION AUTHORISATION