Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RemoteBindAddress = hostname instead of IP address is silently ignored and server binds to all interfaces (nothing in the firebird.log nor syslog) [CORE2087] #2521

Closed
firebird-automations opened this issue Sep 17, 2008 · 15 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: Cosmin Apreutesei (cosmin_ap2)

Block progress on CORE2094

netstat -l shows *:3050 LISTEN and I am able to connect from any interface, even though I specified RemoteBindAdress to just one hostname.

Is giving hostname not supported for this option, and thus this behavior expected (but at least an error in syslog would be nice) ?

Commits: 58c91b1 14f21f5

@firebird-automations
Copy link
Collaborator Author

Modified by: @AlexPeshkoff

assignee: Alexander Peshkov [ alexpeshkoff ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @AlexPeshkoff

Giving hostname is not supported for this option.
But certainly listening to all interfaces in case of user error is not correct behavior. I will take a look, what can be done in this case. Suppose writing a message in a log file and listening only at 127.0.0.1 will be correct behavior.

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

I think the usual behavior to deal with wrongly specified config option is to log this fact and use a default value instead. In our case, the default value means listening to all interfaces available. So I'm not really convinced this is a bug.

@firebird-automations
Copy link
Collaborator Author

Commented by: @AlexPeshkoff

I'm agreed in most cases we go this way. But this is a security issue - if we use default value, server listens on all interfaces, which is IMO not secure behavior - imagine one of them is external interface. Yes, we must log an error - but who reads log when software works? It's much safer to use localhost interface in this case. BTW, a lot of daemons (like bind, for example) do not listen on any interface when misconfigured. Or do not start at all.

I also suggest to add host name resolution for a value, read from firebird.conf. Looks like it's trivial improvement.

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

OK, agreed. However:

> I also suggest to add host name resolution for a value, read from firebird.conf.

And what network card do you suggest to bind the listener then, provided that we're speaking about a multi-homed host?

@firebird-automations
Copy link
Collaborator Author

Commented by: @AlexPeshkoff

Different interfaces on single host may have different host names. I've configured my box in this way to test this feature.

@firebird-automations
Copy link
Collaborator Author

Commented by: Cosmin Apreutesei (cosmin_ap2)

Standard behavior of unix servers is to throw parsing and initialization errors to stderr and syslog and refuse to start (the idea is not to assume unintended behavior-- i.e. even if the server falls back to default behavior, it's still contrary to user's expectation or intuition of what happened).

In the case address binding is configured with hostnames instead of IP addresses, the success of server start/restart could be then bound to the availability of a DNS server (assuming gethostbyname will only be called on server startup, and only once). Apache for instance has an entire documentation page dedicated to the issue (http://httpd.apache.org/docs/2.2/dns-caveats.html). Regardless of their warnings, I still consider using hostnames instead of IP addresses a good practice as it keeps IP address allocation issues away from servers' config files.

Just my 2cents.

@firebird-automations
Copy link
Collaborator Author

Commented by: @AlexPeshkoff

Not starting server at all is certainly the simplest thing which may be done when it's misconfigured. But in most cases we try to avoid such serious answers to configuration error, and for unusable bind address I see only one safe answer - listen at 127.0.0.1. Startup failure is bad answer - when used on windows, server also can listen to WNET/XNET connections (why not let it start for that protocols), and having different behavior on different OS's is not good when can be easily avoided.

What about use of hostname instead of IP address - well, I see no problems improving this feature in 2.5.

@firebird-automations
Copy link
Collaborator Author

Modified by: @AlexPeshkoff

Link: This issue block progress on CORE2094 [ CORE2094 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @AlexPeshkoff

Traditionally we use default value in case of errors in firebird.conf. But for some entries this is unsafe - for example, in this case instead of listen all it's much better to bind 127.0.0.1.

@firebird-automations
Copy link
Collaborator Author

Modified by: @AlexPeshkoff

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

Fix Version: 2.1.2 [ 10270 ]

Fix Version: 2.5 Beta 1 [ 10251 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

status: Resolved [ 5 ] => Closed [ 6 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: Cosmin Apreutesei (cosmin_ap2)

You can test the safety of this protocol in real life. Whenever you forget your wrist watch and someone asks you what time it is, just say it's exactly midnight, 00:00 :) Or, how would you like if your GPS software would default the destination for you when you input a non-existent one :) I can go like this forever.

Defaults are not safe, just annoying, and go counter to user's expectation. I promise to drop a line on this "fixed" request whenever this will bite me again :) The safe answer when you can't compute the answer to a question is an honest 'I don't know'.

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

QA Status: No test

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

status: Closed [ 6 ] => Closed [ 6 ]

QA Status: No test => Cannot be tested

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants