Running consoles as separate Unix users?

[1Bayshore]

Currently, all game code, with the exception of a few key git communication pieces, are run under the gameserver user. While this is handy for server-side communication, it is not ideal for a number of reasons:

• File editing through the server is not ideal because:
  • We have to keep track of our own lists of who can and cannot edit a file.
  • When the git pull command is run, it causes the Unix permissions on some of the files to change, making the gameserver user unable to write them.
  • Since we allow users to run python code in the game, we cannot entirely prevent them from overwriting files that they should not have the permission to edit.
  • Because of the above problem, some files are, as a safety measure, completely unable to be edited in-game. This isn't a huge issue, but it might be nice to allow someday.
• If the game crashes, there is no console landing page explaining to players or allowing wizards to view the problems.
• The login handling, which is a complicated state machine, is located in player.py. This seems a bit clumsy, as it creates unnecessary player for the sole purpose of accessing the state machine. It also allows players to get stuck in the login process if they try to quit during login. We could make several improvements to this code by locating it with the websocket connections.

Proposal: Run the Console and the websocket server as separate processes in separate users

The implementation of this would look something like this:

• [ ] We would create a new Unix user which ran the websocket server and the consoles of all non-wizard players
  • [ ] This user should handle all of the passwords, because nobody (possible exception of gameadmins) can run code as this user
• [ ] The login code would be handled by websocket server.
• [ ] If a wizard player logs in, the websocket server would detect that and redirect them to their Unix login.
  • [ ] Password handling here requires high security. Perhaps we hash what the user types in before sending it from the client, and then use the hash as the actual password to the server.
  • [ ] If we want to create a new wizard, this entails creating a new Unix user. We could give this power to the websocket server, as it should be secure, but we might want to instead create a script to do it manually. (I believe that creating users requires root access.)

In addition to the already mentioned, there are a number of cool features that would be enabled by using more Unix users:

• Console customization: Wizards could customize their own consoles on the server and implement additional features
• Multiple players: Wizards (and possibly others) could control multiple players from inside the console

Difficulties:

• Creating Unix users: This requires high privileges, and so automating it might be difficult. Even if so, we might be opening a dangerous security hole.
• Git commits: Git might still overwrite the users, groups, and permissions on files during a git pull. Line endings (see #171) could become a problem as well.
• Secure passwords: ideally, players should not have to enter their passwords upon connecting to their console and then again on connecting to their player. We should also make sure that players cannot connect to someone else's player from their console. (Idea: save/load player files in console and send them to gameserver?)
• Console usage within game: We make calls to various console functions from within the game a lot, including in all action functions. We might want to make a ConsoleAccessPoint class that redirects some of these function calls to various player/console functions.

[rivques]

Password handling here requires high security. Perhaps we hash what the user types in before sending it from the client, and then use the hash as the actual password to the server.

The thing about this is that we still have the actual password being sent across the internet, it's just not seen by the user. I don't understand what this changes, because you would have to ensure a totally secure connection either way. All that hashing does in this case is turn the password into a number.