My cvar latch system changes prevent the Game VM from changing
g_gametype when the value is out of range due to it being registed in
the engine. It's been pointed out as fragile method of security, which
was still exploitable, by Noah Metzger (Chomenor). It doesn't seem like
this is working out to be a good solution.
The issue of fs_game '..' on server being relicated on client via
systeminfo exploit is still fixed as it's not affected by latch.
There are a few cases from current values of fs_game are used which
ideally should use fs_gamedir char array which has been validated.
Revert "Don't let VMs change engine latch cvars immediately"
Partially revert "Fix fs_game '..' reading outside of home and base path"
Revert "Fix VMs forcing engine latch cvar to update to latched value"
VMs could set fs_game to '..' at anytime to access files outside of home
and base path. fs_game sent by server to clients could also be '..' to
access files outside of home and base path.
'..' was not caught by FS_CheckDirTraversal() as it expects filenames
not a single directory.
I've made fs_game be latched to prevent VMs from changing it with no
good way to validate it before it's used. com_basegame and fs_basegame
are now latched as well.
Additionally, it's now possible to change com_basegame while the engine
is running. game_restart or vid_restart will make it take affect.
com_homepath is now CVAR_PROTECTED to prevent VMs from changing it
to a directory traversal.
This requires my two previous commits for preventing VMs from changing
engine latch cvars and only Cvar_Get fs_game in FS_Startup (so CVAR_INIT
isn't added in serveral other places).
Reported by Noah Metzger (Chomenor).
- Paths to search for mods are now specified in an array
- Mods can now consist solely of ".pk3dir" folders and still be
considered valid
- The function now has a consistent style
Offer to restore settings when loading a mod that crashed, not the first
mod that gets loaded after a crash. Before the first mod loaded (usually
baseq3) would get the option even if missionpack or some other mod crashed.
- Make pid files separate for each fs_game.
- Remove/write pid every time switching fs_game.
- Create path before writing pid file otherwise it fails on first run.
- Show mod description.txt or fs_game instead of engine name in abnormal
exit message.
- Check com_fullyInitialized in Com_Error before removing PID,
otherwise "ioquake3 --version" segfaults when accessing fs_gamevar->string
(plus not fully initialized isn't really a normal shutdown).
If a pk3 search path is passed to FS_FOpenFileReadDir, a non-zero
file handle is returned if file is not found. This causes incorrect
behavior in FS_ReadFileDir (when a pk3 search path is passed in)
which only checks file handle, not length, for seeing if file exists.
I don't know of any issues in ioq3 caused by this.
FS_FOpenFileRead is a fairly mental function that changes its return
behaviour depending on whether or not file is NULL or not. It turns out
in the case where file is NULL, we were returning the wrong value when
the file didn't exist.
Zack Middleton