FRIK_FILE sanity

[mh]

If you've implemented FRIK_FILE you've probably noticed that opening a file in append mode is a thing of true evil. Let's bring that warm fuzzy glow of sanity to it.

First replace your PF_fopen with this version:

Code: Select all

void PF_fopen (void)
{
	char *p = G_STRING(OFS_PARM0);
	int fmode = G_FLOAT (OFS_PARM1);
	int h = 0;

	switch (fmode)
	{
	case 0: // read
		Sys_FileOpenRead (va("%s/%s",com_gamedir, p), &h);
		break;

	case 1: // append -- sane version
		h = Sys_FileOpenAppend (va("%s/%s", com_gamedir, p));
		break;

	default: // write
		h = Sys_FileOpenWrite (va("%s/%s", com_gamedir, p));
		break;
	}

	// always common now
	G_FLOAT (OFS_RETURN) = (float) h;
}

Now add this to sys_win.c (or whatever, depending on your platform):

Code: Select all

int Sys_FileOpenAppend (char *path)
{
	FILE	*f;
	int		i;

	i = findhandle ();
	f = fopen (path, "ab");

	// change this Sys_Error to something that works in your code
	if (!f)
		Sys_Error ("Error opening %s: %s", path, strerror (errno));

	sys_handles[i] = f;
	return i;
}

And finally add this to sys.h:

Code: Select all

int Sys_FileOpenAppend (char *path);

No further explanation needed, I hope.

[Team Xlink]

Great tutorial.

I have a question on a possible further expansion to it:

Code: Select all

   switch (fmode) 
   { 
   case 0: // read 
      Sys_FileOpenRead (va("%s/%s",com_gamedir, p), &h); 
      break; 

   case 1: // append -- sane version 
      h = Sys_FileOpenAppend (va("%s/%s", com_gamedir, p)); 
      break; 

   default: // write 
      h = Sys_FileOpenWrite (va("%s/%s", com_gamedir, p)); 
      break; 
   } 

If we wanted to be able to open files from the root directory of the quake folder we should be able to use something other then com_gamedir, correct?

This would make sense in the case that you have several versions of the same mod, or different mods who all use the same file, doing this you wouldn't have to copy and past the file in each mods directory.

Would this work, are there any problems or possible errors that may appear when doing it this way?

[mh]

I think it would be better to put the file into ID1 and mod FRIK_FILE to use COM_OpenFile instead. I don't like the thought of the engine being able to change files outside of a gamedir.

[Sajt]

According to the DarkPlaces paradigm (of security) it shouldn't be possible, and that's a feature!

[Spike]

According to the DarkPlaces paradigm (of security) it shouldn't be possible, and that's a feature!

when you support auto-downloading csqc, not even being able to read the gamedir is a very sensiblefeature.

[mh]

It's bogus security anyway; any kind of client-side security is completely and utterly 100% bogus, for the simple reason that there's nothing to stop someone from downloading the code, modifying it, recompiling it, and redistributing it.

I do think it's a nice checkbox to have - "I'll play nice with you and keep my grubby little hands where they belong" - but most definitely not "security".

[Sajt]

I think it's reasonable to say that the user is responsible for which exe he installs. If he takes a hacked exe from an acquaintance (or non-acquaintance), instead of simply downloading the official one (with an md5 checksum and everything), you can say he has voided the warranty, and completely deserves to have his harddrive reformatted by a malicious/buggy autodownloaded progs.dat.

When the user is responsible for the exe alone, but the exe takes care of everything else, I call this security. Sure, it doesn't protect against someone hacking his computer and tampering with his files. But then, anything on his computer could be hacked. It also doesn't protect against his house being blown up by a suicide bomber. But I think that REASONABLY speaking, this can safely be called "security".