Re: Disabling trust/ident authentication configure option - Mailing list pgsql-hackers
| From | Volker Aßmann |
|---|---|
| Subject | Re: Disabling trust/ident authentication configure option |
| Date | |
| Msg-id | CAJBpAdykziErDdZ1_ud_AfZGYCkYsMAuuhwxMHYewOsBdQGSJg@mail.gmail.com Whole thread Raw |
| In response to | Re: Disabling trust/ident authentication configure option (Robert Haas <robertmhaas@gmail.com>) |
| List | pgsql-hackers |
On Wed, May 20, 2015 at 5:21 PM, Robert Haas <robertmhaas@gmail.com> wrote:
Please don't be discouraged here. Contributing to the PostgreSQL
community can be frustrating when you don't get what you want, and
even though I have been a member of this community for about 7 years
now and am a major contributor and committer, I still very often do
not get what I want.
But please don't view that as a personal rejection. I stand by what I
said: disallowing trust authentication in pg_hba.conf will not slow
down an attacker who wants to create a backdoor. I believe that to be
true, and I can tell you why, but regardless of anything I say, you
can still believe it to be false. I'm OK with that, and I hope you're
OK with me having a different belief. It doesn't mean that I don't
want you to continue reading this mailing list or suggesting things;
in fact, I hope you will. The fact that I (and others) don't like
this particular idea doesn't mean we won't like your next one, or the
one after that.
If this discussing has come across as bruising, I apologize for that.
One of the things that sometimes happens is that somebody submits a
patch and it goes for a long time without receiving any meaningful
feedback. Then eventually, sometimes after a lot of work has been put
into it, it gets rejected. That's not fun. So another approach is
for people to respond right away when somebody posts a patch that they
think is a bad idea and say: hey, wait, let's not do this, I think
it's a bad idea. But then you can have a situation (which I think may
have happened in this case) where a contributor feels that other
people are jumping all over them. That's not fun, either.
I don't know the answer to this problem. I'm not the world's greatest
diplomat, and tone is even harder to read over email than it is in
person. But I can tell you that I'm not mad at you personally, and I
didn't spend time replying to this email thread just to get rid of
you. If it came across that way, I'm sorry.
Yes I guess discussing via mail always lends itself to misinterpretations, and people tend to read the worst possible interpretation :) So I am not offended and also did not intend to offend you in my reply.
I likely just viewed this too much through a "security" lens - you see a possible attack scenario, a way to turn it off, and only minor downsides, so just go for it - but this is not how you can work in a huge open source project. I guess as a developer you would have to take many other issues (like maintainability, user confusion because of the change, edge use cases) into account. And as it seems to cause too much trouble for "official inclusion" I am fine with patching it during our package build.
I likely just viewed this too much through a "security" lens - you see a possible attack scenario, a way to turn it off, and only minor downsides, so just go for it - but this is not how you can work in a huge open source project. I guess as a developer you would have to take many other issues (like maintainability, user confusion because of the change, edge use cases) into account. And as it seems to cause too much trouble for "official inclusion" I am fine with patching it during our package build.
And yes once someone has write access to your pg_hba.conf you are very likely doomed. This would just prevent an attack happening through a careless "trust" entry left there, which is just a very quick win for an attacker, and may be a bit less likely through this patch.
To answer to Tom: I see a restricted audience for this patch, but also no impact for anyone not wanting to use it. The group of users I see would be as follows:
* People who package PostgreSQL as part of their product and want to provide their customers with a restricted "more secure" functionality set only to reduce training and support effort. (my use case)
* People with large Postgres deployments who build their own packages and want to enforce a certain security policy (e.g. services are not allowed to offer authentication-less access over the network)
- specifically a good security plan would be to only allow a "safe subset" of methods and ensure that these are well documented and perhaps audited automatically
- this would also allow ensuring there is only one documented / audited way to reset passwords (modulo single user mode, that is an additional problem which won't be easily fixable)
* Distributions which want to provide a more secure package and want to ensure each available method can be configured securely and documented clearly for their specific setup.
It does not apply to (or would have a negative effect for) the following groups:
* PostgreSQL users on Windows (disabling trust should not work or should show a very prominent warning)
* Users of default builds (they simply won't be affected)
* People with a specific use case requiring "trust", "ident" or for the more generic patch other specific auth methods. They will be affected if they happen to be using a build with this method turned off.
* People who are used to resetting passwords using "trust" and are surprised this suddenly does not work on some specific system
My guess is the group who actually profit is relatively small, but the group of people actively affected would also be relatively small. I have no idea about actual usage so I am not qualified to judge here :)
pgsql-hackers by date: