mumble-server password content causing database corruption

[Erik Stambaugh]

Binary package hint: mumble

mumble-server package version 1.2.2-1ubuntu1 from ubuntu 10.04 LTS beta

This is really weird. On the canonical mumble server (morinda), we have 139 registered user IDs. Recently added users are unable to access the server, getting invalid login/password responses.

We're administering the server via dbus-send on the command line. Using these command line tools, we can retrieve the broken users' info when requested by numeric user ID, but not by nick. For example:

squinky@morinda:~/$ dbus-send --system --print-reply --dest=net.sourceforge.mumble.murmur --type=method_call /1 net.sourceforge.mumble.Murmur.getRegistration int32:135
method return sender=:1.2 -> dest=:1.8793 reply_serial=2
   struct {
      int32 135
      string ""cyphermox""
      string ""<email address hidden>""
      string ""
   }

However, when getting the user's info by their string nick, it comes back blank:

squinky@morinda:~/$ dbus-send --system --print-reply --dest=net.sourceforge.mumble.murmur --type=method_call /1 net.sourceforge.mumble.Murmur.getRegisteredPlayers string:""cyphermox""
method return sender=:1.2 -> dest=:1.8794 reply_serial=2
   array [
   ]

By way of comparison, here are the responses we get with a known working uid:

squinky@morinda:~/$ dbus-send --system --print-reply --dest=net.sourceforge.mumble.murmur --type=method_call /1 net.sourceforge.mumble.Murmur.getRegistration int32:1
method return sender=:1.2 -> dest=:1.8796 reply_serial=2
   struct {
      int32 1
      string "squinky"
      string "<email address hidden>"
      string ""
   }
squinky@morinda:~/$ dbus-send --system --print-reply --dest=net.sourceforge.mumble.murmur --type=method_call /1 net.sourceforge.mumble.Murmur.getRegisteredPlayers string:""squinky""
method return sender=:1.2 -> dest=:1.8797 reply_serial=2
   array [
      struct {
         int32 1
         string "squinky"
         string ""
         string ""
      }
   ]

Here is kind of a messy illustration of the problem, finding each nick in order, then searching for their uid. I'm skipping many uids that come back correctly, just to keep the output brief. It's only the last few that don't find their uid:

for I in `seq 125 139`; do NICKBYUID=`dbus-send --system --print-reply --dest=net.sourceforge.mumble.murmur --type=method_call /1 net.sourceforge.mumble.Murmur.getRegistration int32:$I | grep -m 1 string | awk ' { print $2 }' | sed -e 's/"//g'`; echo -n "$NICKBYUID: "; UIDBYNICK=`dbus-send --system --print-reply --dest=net.sourceforge.mumble.murmur --type=method_call /1 net.sourceforge.mumble.Murmur.getRegisteredPlayers string:$NICKBYUID | grep -m 1 int32 | awk '{ print $2 }'`; echo $UIDBYNICK; done
therve: 125
free: 126
al-maisan: 127
kapil: 128
kdraks: 129
andreas: 130
jkakar: 131
Kaleo: 132
hlh: 133
kfogel:
cyphermox:
sbeattie:
ameetp:
imlad:
ara:

I suspect some sort of database corruption. Our interactions with murmur are all limited to dbus commands, and those are carefully controlled by a script (barring the manually-entered stuff you see above). There are no strange characters or anything in these users' data from what I can see.

I worked around it by going through each failing user, one at a time, and resetting their passwords. Murmur must be accepting some sort of bad strings through dbus for passwords (I didn't set these users up, so I don't know what they contained), causing it to fail on string lookup for the uid. If that's the case, it seems pretty clear that at least some string validation needs to be put into it.

[Erik Stambaugh (squinky)]

An update: it looks like it's not a string validation problem. I was told that the passwords assigned to users were plain alphanumerics. This sounds more like database corruption now.

[Thorvald Natvig (slicer)]

Any chance you could send me a copy of the sqlite database, as well as any modifications to .ini / defaults files you've made? Will be much easier to fix if I can replicate the conditions here :)

[Thorvald Natvig (slicer)]

We'd like to figure out what's causing this bug for you, but we haven't heard back from you in a while. Could you please provide the requested information? Thanks!

[Leo Arias (elopio)]

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!