Skip to content

[2.0] InspIRCd should not unload all modules if it cannot locate a remote include on rehash #30

Closed
Justasic opened this Issue Apr 6, 2012 · 9 comments

6 participants

@Justasic
Justasic commented Apr 6, 2012

I am tired of seeing this: http://pastie.org/3740805 because I rehash and something in my DNS changed (dynamic DNS) and no longer resolves, thus causing inspircd to unload ALL core modules thinking that part of the config is now gone. Instead I think it should abort the rehash and maybe allow some kind of conformation override.

I also believe that when a DNS hostname is placed in the link:ipaddr block that the hostname be resolved at every rehash instead of being cached, it makes Dynamic DNS very annoying to work with when your old ip is cached.

@Shawn-Smith

Maybe it could cache the config file each time and then on future rehashes if it can't find the remote one it can resort to the cache.

@SaberUK
SaberUK commented Apr 6, 2012

Not being able to access a remote include is an error and should be treated as such. In my opinion the correct behavior should be to abort the rehash and inform the rehashing user of the error. Caching the file as suggested by @Shawn-Smith could introduce unintended configuration errors of potentially disastrous significance.

@blitmap
blitmap commented Apr 10, 2012

I imagine the rehash is being done as it goes down the config, so if it can't locate a remote include, it's already applied a section of the "new config". It would be a lot more work to first undo what has been applied, and then abort the rehash....

I would abort doing anything else if the remote include cannot be gotten to. So a partial application, not a more clever abort of a rehash :>

Two things to implement:

1) Stop at the point where a remote include fails when rehashing. Abort doing "the rest of it".
2) Don't cache the IP of the host given in the remote include, resolve with each rehash to avoid screwing up dynamic DNS setups. (perhaps someone should look for other non-user IPs being cached elsewhere? -- dynamic DNS setups are becoming more common)

Later :o

I'm blabbering, just thought I'd add that... (for anyone who wants to try implementing this)

@Justasic

well I didn't think about dynamic dns on the resolution of remote includes but that would be an issue as well, I was saying that link blocks need to resolve the address everytime a /connect is given to the sever or your dyndns is going to get cached and end up causing more issues than should happen. I know this happens even after /cleardns, it results in me manually adding the ip address into the link block. Just some thoughts I guess, I do admit it will be quite a feat to get the config parser to not follow this behavior.

@Justasic

Also as an added note, I think there should be a override ability to allow the daemon to continue starting even if there are modules that cannot be found

@kaniini
kaniini commented May 23, 2012

@Justastic dynamic DNS + remote includes combined is a major security flaw, are you sure your configuration is actually valid?

@SaberUK
SaberUK commented May 23, 2012

I think the best way to fix this would be to fail the rehash if an executable include returns a value other than EXIT_SUCCESS in ParseStack::ParseExec().

@Justasic

@nenolod yes, I understand that dynamic DNS is a security flaw but hosting under 18 means I have to accept it and do my best to mitigate it. Yes the configuration is valid, it's just a bit annoying that inspircd caches the ip from the resolved hostname to save time (what? 3 ms?). The reason why I asked to allow the daemon to continue starting even if there's no module found is because when I make a testnet I don't want to redo my configs, I would rather use my network's configs while ignoring a few extra modules, if that makes sense.

@SaberUK Yeah, that's what I was thinking.

@attilamolnar
inspircd member

solution implemented in https://github.com/attilamolnar/inspircd/compare/insp20%2Bmandatorytag, comments are welcome

@attilamolnar attilamolnar added a commit that closed this issue Mar 20, 2013
@attilamolnar attilamolnar Add support for mandatory tags in included config files
If the mandatory tag is not found in the included config, the rehash is aborted. This is especially useful for remote includes, as it allows users to have a dummy tag at the end of the included config to indicate that the config has been wholly read.
This method does not depend on exit codes so even situations where wget returns an empty or a wrong page that we would otherwise accept can be detected and an error can be generated before we assume that the contents have disappeared (and unload all modules, if the included file is supposed to contain module tags, for example).

Usage: <include ... mandatorytag="namehere"> - if the included config doesn't contain a <namehere> tag then the rehash is aborted

Fixes #30 reported by @Justasic
fd6a8e9
@satmd satmd added a commit to satmd/inspircd that referenced this issue Jun 1, 2014
@attilamolnar attilamolnar Add support for mandatory tags in included config files
If the mandatory tag is not found in the included config, the rehash is aborted. This is especially useful for remote includes, as it allows users to have a dummy tag at the end of the included config to indicate that the config has been wholly read.
This method does not depend on exit codes so even situations where wget returns an empty or a wrong page that we would otherwise accept can be detected and an error can be generated before we assume that the contents have disappeared (and unload all modules, if the included file is supposed to contain module tags, for example).

Usage: <include ... mandatorytag="namehere"> - if the included config doesn't contain a <namehere> tag then the rehash is aborted

Fixes #30 reported by @Justasic
48a9d73
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.