Linux Game Development Part 3

Quote:

On a Linux system, you should write saved game files, configuration files, high score lists, etc. to the player’s home directory. You can determine the player’s home directory in your C/C++ program by reading the HOME environment variable, like this: char* home_dir = getenv(“HOME”); if (home_dir != NULL) { // build the path to your game files }

Please don't do that. Changing an environment variable is dead easy and it'll cause your program to fail (at best) or to write in the wrong location. A more robust way is:

#include <unistd.h>#include <sys/types.h>#include <pwd.h>#include <stdlib.h>struct passwd *passwd;if (NULL != (passwd = getpwuid(getuid())) {  char *home_dir = passwd->pw_dir;  /* ... */}

This will return the correct home directory (using the process ID) regardless of the environment variable. The only way this could cause trouble is if the file has a set ID (which should never happen for a game, but could potentially be useful for a server). In that case, geteuid(2) might be what you're after, depending on your needs.

EDIT: fixed error spotted by Codexus.


[Edited by - let_bound on August 11, 2007 8:33:36 AM]

Cool article!

@let_bound: In my opinion, your solution is ten times worse. You're assuming that the username will match the home directory's name and then, while you left that part out, you'll probably assume that the home directory is in "/home/". While this is usually the case this is not guaranteed.

Yes, the HOME environment variable can be changed, so what? The reason why you'd change it is precisely so that programs will use it as the location of your home directory. Trying to find a way around that is just going to make your program behave in a way that the users won't expect.

@let_bound: Actually, I realize that maybe you meant to type "pw_dir" instead "pw_name" in which case your solution is somewhat OK but still it's recommended to use the "HOME" variable to allow people to change it.

Quote:

Original post by Codexus @let_bound: Actually, I realize that maybe you meant to type "pw_dir" instead "pw_name" in which case your solution is somewhat OK but still it's recommended to use the "HOME" variable to allow people to change it.

Yes, I did. I'll edit the code to reflect this. As for allowing the user to change it, I disagree with it, if only because you actually must obtain a value (in order to read/write the files) and the environment variable can be unset, or incorrectly set. getpwuid(3) will at least return a valid string if the user exists and has a home directory.

I personally find that environment variables are great for tweaking behaviour, but I don't think one should depend on them being correctly set, or set a all. I guess I wrote too much server-side code in my life to trust them. YMMV.

Quote:

Original post by let_bound Please don't do that. Changing an environment variable is dead easy and it'll cause your program to fail (at best) or to write in the wrong location.

If the user is overwriting HOME, they probably have a good reason. Most other programs which write to your home directory respect the HOME variable. If the user is overwriting HOME, other programs would observe the new value and the user would be expecting your program to follow suit. Why should your program surprise the user?

Quote:

This will return the correct home directory (using the process ID) regardless of the environment variable.

The correct home directory is the directory in the HOME environmental variable. That's what the variable is for.

Quote:

Original post by let_bound As for allowing the user to change it, I disagree with it, if only because you actually must obtain a value (in order to read/write the files) and the environment variable can be unset, or incorrectly set.

And? The user would have to go out of their way to unset HOME, or set it to something that isn't a directory the program can write to. If they have, the program can simply display an error message. If HOME really is bad, the user has a serious problem with their system which will probably effect many other programs they run, so it needs fixing anyway.

Quote:

I personally find that environment variables are great for tweaking behaviour, but I don't think one should depend on them being correctly set, or set a all. I guess I wrote too much server-side code in my life to trust them. YMMV.

Client-side code is completely different. If something is wrong, the user knows immediately and can fix it right there. Besides, if you can't depend upon HOME being set, you have bigger problems.

[Edited by - Nathan Baum on August 11, 2007 9:22:58 AM]

Great discussion guys!

Let me just add my experience from the past 8 months of distributing Dirk Dashing on Linux: I haven't had one problem report involving the use of the HOME environment variable. I think this use of HOME is safe in practice, and is generally accepted and expected by users.

Quote:

Original post by Nathan Baum Quote: Original post by let_bound As for allowing the user to change it, I disagree with it, if only because you actually must obtain a value (in order to read/write the files) and the environment variable can be unset, or incorrectly set. And? The user would have to go out of their way to unset HOME, or set it to something that isn't a directory the program can write to. If they have, the program can simply display an error message. If HOME really is bad, the user has a serious problem with their system which will probably effect many other programs they run, so it needs fixing anyway.

You're probably right, although I still feel uncomfortable with the idea of allowing potentially anyone to write to/read from someone else's home directory by mistake if the permissions aren't correct. I do realize they'll likely be restrictive enough to disallow at least writing. It's probably my paranoid self speaking.

Quote:

Quote: I personally find that environment variables are great for tweaking behaviour, but I don't think one should depend on them being correctly set, or set a all. I guess I wrote too much server-side code in my life to trust them. YMMV. Client-side code is completely different. If something is wrong, the user knows immediately and can fix it right there. Besides, if you can't depend upon HOME being set, you have bigger problems.

I'm quite aware that client-side is completely different. I mentioned my writing server-side code to explain my view on the subject of software engineering. Sometimes I tend to go overkill with stability and security, at the expense of simplicity. It's in my nature to think of users as misbehaving bastards. [grin]

Quote:

Original post by let_bound You're probably right, although I still feel uncomfortable with the idea of allowing potentially anyone to write to/read from someone else's home directory by mistake if the permissions aren't correct.

Nobody sets their HOME to somebody else's home directory by mistake. Somebody doing that is doing it on purpose, and will already know if they can read from or write to files in somebody's home directory. They wouldn't need to use the game to do that.

The only time using HOME would be a problem is if the game executable was setuid, since I could have HOME refer to a directory I wouldn't normally be able to write to. But relying on /etc/passwd to keep a setuid program secure would also be a problem, since I could make ~/.game a symlink to another user's directory.

Quote:

I'm quite aware that client-side is completely different. I mentioned my writing server-side code to explain my view on the subject of software engineering. Sometimes I tend to go overkill with stability and security, at the expense of simplicity. It's in my nature to think of users as misbehaving bastards. [grin]

But this isn't the way to solve it. If overriding HOME enables a user to bypass security, then you have security problems which can't be reliably resolved simply by using /etc/passwd instead.

Quote:

Original post by Nathan Baum Nobody sets their HOME to somebody else's home directory by mistake. Somebody doing that is doing it on purpose, and will already know if they can read from or write to files in somebody's home directory. They wouldn't need to use the game to do that.

I was hoping to be done with that argument, given the text you quoted (no offense). I can hardly do more than saying "you're right". [smile] My discomfort is a feeling, and I never meant to imply it's in any way, shape, or form, logical or justified.

When I said "by mistake", I meant "without the user realizing it's mischievous". Obviously it's impossible to know what "HOME=/home/foo bar" does and to type it by mistake. But nobody's that interested in saved games and highscore anyway, so this isn't relevant to this discussion.

Quote:

The only time using HOME would be a problem is if the game executable was setuid, since I could have HOME refer to a directory I wouldn't normally be able to write to. But relying on /etc/passwd to keep a setuid program secure would also be a problem, since I could make ~/.game a symlink to another user's directory.

That's correct.

Quote:

Quote: I'm quite aware that client-side is completely different. I mentioned my writing server-side code to explain my view on the subject of software engineering. Sometimes I tend to go overkill with stability and security, at the expense of simplicity. It's in my nature to think of users as misbehaving bastards. [grin] But this isn't the way to solve it. If overriding HOME enables a user to bypass security, then you have security problems which can't be reliably resolved simply by using /etc/passwd instead.

I guess I should only blame myself for typing more than I should. I wasn't pretending getpwuid would improve "security". I simply was saying than I tend to go for stability and security over everything else because of my background, regardless of the "getenv vs getpwuid" subject.

In this case, I'd have gone with getpwuid out of habit. I realize my programming style has been tainted by too much server-side coding, and that's why I said you're probably right, than it's my paranoid self speaking, and than it's in my nature to be wary of users.