Config file disappeared - Unclassified NewsBoard

Reply · Quote

codethief

2009-06-18, 14:29 #1

Member since Feb 2007 · 5 posts · Location: Berlin
Group memberships: Members

Show profile ·

Link to this post

Subject: Config file disappeared

Hello dear community,

today I went to my forum (as I do every day) and I'm told:

UNB error: The configuration file could not be read. Did you install the board?

Yes, of course I did!
So I tried to find out what the heck happened to my config file and it seems like it literally disappeared. There is absolutely no config file in my board's directory! Yesterday, everything was still working fine.
Might this have something to do with the recently found security bugs? Could someone have been able to delete the config file?

Reply · Quote

Yves (Administrator) 2009-06-25, 21:06 #2

User title: UNB developer & webmaster
Member since Jan 2004 · 3740 posts · Location: Erlangen, Germany
Group memberships: Administrators, Members

Show profile ·

Link to this post

Possibly. Is there a temporary copy of your config file still around? It should be named like board.conf.php.tmp. If this exists, just rename it and you're done. Though I haven't seen any case where this has failed. To find out whether somebody had access to your web server through the board, you may analyse the web server and board access log files. But be aware that the board access log files can be manipulated through board-induced code as well, while the web server logs should be safe on a decent server setup.

♪ ...nanananah, all in all we’re just brilliant thieves, nanananah... ♪♬

Reply · Quote

codethief

2009-06-28, 18:29 #3

Member since Feb 2007 · 5 posts · Location: Berlin
Group memberships: Members

Show profile ·

Link to this post

No, there wasn't any .tmp file.

Reply · Quote

nicoduck 2009-12-07, 21:09 #4

Member since May 2007 · 8 posts
Group memberships: Members

Show profile ·

Link to this post

hi

i have exactely the same error.

it first appeared about half a year ago, i checked all logs and could not find anything suspicious.
the second time was thursday last week and the third time (until now) was today

i have no idea how it happens, there is nothing special happening on the server and i could not reproduce the problem.

in all the three times it happend it worked minutes before so it must have come from loading the page.
i thoght it might come frome some malformed requests while firefox restores a session but also, not reproducable (on demand)

i now secure the file with the commant "chattr +i board.conf.php", an filesystem specific command (ext3 in my case) which sets the immutable bit, not allowing any changes by anyone (even not root and the owner of it) until it is removed (with chattr -i), this should help (for now) (chattr +i and -i can only be used by root, so only on root or virtual-root servers)

@yves if you have any questions, feel free to concact me, maybe i can help

greetz

nico

Reply · Quote

Yves (Administrator) 2009-12-07, 21:43 #5

User title: UNB developer & webmaster
Member since Jan 2004 · 3740 posts · Location: Erlangen, Germany
Group memberships: Administrators, Members

Show profile ·

Link to this post

I can't really tell what ghost is in there. Here's something for you to try out:

Edit the file unb_lib/common.lib.php around line 2037. It looks like this:

if ($usetemp && !@rename($conf_tempname, $conf_filename))
    {
      // Windows compatibility (?): try again, but first delete target file for rename()
      if (!unlink($conf_filename)) return false;
      if (!rename($conf_tempname, $conf_filename)) return false;
    }

1. Remove the @ character right before the rename() call. It would drop any error messages that might occur in the rename call. If anything goes wrong here, the error will be logged in PHP's error log. Ask your system administrator where to find that.

2. Comment out both code lines within the if block. (The two lines under "// Windows compatibility".) Put a # character or // at the beginning of both lines. Usually, the conf file is not written to directly, but instead a tmp file is written to which is then atomically renamed to the new conf file. This either succeeds completely or fails and does not change anything. Windows doesn't support this atomicity and therefore requires special care. Also, if the board could not create the new tmp file, it silently skips that extra safety and again writes directly to the conf file, which is potentially less safe. And the unlink() call here potentially deletes the file and leaves it that way (unlink means delete), so commenting out this line may help to not delete the conf file.

This, however, is only a half-way test. If the conf file should be deleted again after those modifications in the future, we know for sure (well, almost) that those lines were not the problem. But as long as the conf file doesn't disappear, we know nothing and remain uncertain whether this is a definite fix or not.

Sorry, but that's all I can offer at the moment for an unreproducible bug that I personally have never suffered.

Ehm... as I'm writing this... did you check, after the conf file had gone, whether the conf.tmp file was still there? If it was, just give it that tap, rename the file and you're done for now. The problem was then in some rename() call. If it wasn't there, something more serious is broken...

♪ ...nanananah, all in all we’re just brilliant thieves, nanananah... ♪♬