Latest release [1] in core/updates_testing fixes CVE-2012-0049. [1] openttd-1.1.0-1.2.mga1 Suggestion for advisory: ========== This update fixes CVE-2012-0049 (Denial of service (server) via slow read attack). More info: http://security.openttd.org/en/CVE-2012-0049 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0049 ==========
I entered openttd at a terminal several minutes ago. Using strace on the process shows ... Trace of process 30225 - openttd stat64("/home/dave/data/.operabackup/images/templates.services.openoffice.org.idx", {st_mode=S_IFREG|0664, st_size= stat64("/home/dave/data/.operabackup/images/http%3A%2F%2F66.252.134.231%2Ffavicon.ico", {st_mode=S_IFREG|0664, st_s It seems to be recursively running stat64 on every directory/file under my home directory. With a little over 40GB on an encrypted file system, that is going to take far too long. Oh. It just put out some text on the konsole ... $ openttd dbg: [misc] The file '/home/dave/data/software/cleanfeed-20020501.tar' isn't a valid tar-file dbg: [misc] The file '/home/dave/data/software/unix.admin.horror-1.1.tar.tar' isn't a valid tar-file What is this "game" doing? I've killed the process now.
CC: (none) => davidwhodgins
x86_64 # urpmi openttd In order to satisfy the 'timidity-instruments[== 2]' dependency, one of the following packages is needed: 1- timidity-patch-freepats-20060219-14.mga1.noarch: Patch set for MIDI audio synthesis (to install) 2- timidity-patch-gravis-1.0-29.mga1.noarch: Instruments for the timidity midi->wave converter/player (to install) 3- timidity-patch-fluid-3.1-6.mga1.noarch: Pro-quality General Midi soundfont in GUS patch format (to install) What is your choice? (1-3) 3 To satisfy dependencies, the following packages are going to be installed: Package Version Release Arch (medium "Core Release") TiMidity++ 2.13.2 30.mga1 x86_64 fluid-soundfont-common 3.1 6.mga1 noarch openttd-opengfx 0.3.3 1.mga1 noarch (medium "Core Updates") openttd 1.1.0 1.1.mga1 x86_64 (medium "Core 32bit Release") openttd-openmsx 0.3.1 2.mga1 noarch openttd-opensfx 0.2.3 3.mga1 noarch timidity-patch-fluid 3.1 6.mga1 noarch 225MB of additional disk space will be used. 115MB of packages will be retrieved. Proceed with the installation of the 7 packages? (Y/n) y My mirror is having a few troubles so will test x86_64 when it becomes available.
(In reply to comment #1) > > What is this "game" doing? I've killed the process now. Dunno as I can't reproduce this. Works fine, at least on i586.
Testing the current version x86_64 I don't see the behaviour either. In fact I don't see any stat64. The only file stats are on /usr/share/games/openttd/ and ~/.openttd/ Still unable to test the update candidate, hopefully the mirror will sync overnight.
Very strange. If I cd to /home, /, or /home/dave/tmp, before starting the game it's fine. It's only if the current directory is /home/dave that I'm seeing the strange behaviour. Skimming through the code, it looks like it's openttd-1.1.0/src/fileio.cpp in TarScanner::DoScan that's doing the scan, although why it only happens when I'm in my home directory, and doesn't happen if the current directory is /home, is not clear. Anyway, I don't consider this a blocker, as it works fine if started from the menu. As to waiting for the mirror to sync, might be a good idea to switch to the http://twiska.zarb.org mirror.
I've not been able to reproduce the behaviour you've seen Dave. I even removed ~/.openttd and reinstalled before starting and aside from a few X11 checks it isn't stat'ing anything outside those two directories for me. I dont see stat64 being used at all. You can download addons for the game as tar files and the game scans for them at startup to catalogue them, apparently. It is odd that it scans your home directory, you'd think they would be in .openttd if anywhere. It appears to be normal though. Gave up on linuxcabal so testing complete x86_64. Are you happy to validate Dave or do you think it's worth reporting the odd behaviour you're seeing upstream?
It seems it looks in all directories in the current directory, but not recursively. I have 27 symlinks in my home directory, like ~/Documents that link to directories in an encrypted filesystem with a little over 40GB of data. Scanning all of those directories takes quite a while on my system. It isn't a regression. It only happens when you start it from the command line, and you are in a directory where the combined subdirectories have a lot of data, and doesn't happen when you start it from the menu, so I'll go ahead and validate the update. Could someone from the sysadmin team push the srpm openttd-1.1.0-1.2.mga1.src.rpm from Core Updates Testing to Core Updates. Advisory: This security update for openttd fixes CVE-2012-0049, A Denial of service (server) via slow read attack. https://bugs.mageia.org/show_bug.cgi?id=4141
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
update pushed
Status: NEW => RESOLVEDCC: (none) => tmbResolution: (none) => FIXED
Depends on: (none) => 6145
Depends on: 6145 => (none)