I may be crazy, but I know there are some Middle Schoolers who can run a server. So I’m teaching them headless shell management and scripting, all so they can play Minecraft (the carrot, in this case.) They are learning surprisingly well, but then, so am I. I’ve never had to create a fully group setting on Linux, and didn’t anticipate all the issues I’d run in to. Wanting to have 17 kids in an ssh group, with access to a games folder that consistently outputs files they can all use, and allows them to run an instance of Minecraft they can all access… It is a lot to figure out. This series is going to cover the settings I came up with.
Setting up the Group Folder
The plan here, was to have all the group with ssh access have a united home folder that we could work from for our game instances. The top level folder, and everything underneath it, would need to be accessible to the group, not just to the creator, so I played around with some settings, and came up with a solution that worked.
Setting the Permissions right
The first thing I did was create a ‘games’ folder in the ‘home’ directory. I knew I wanted this folder to be a group folder, so I ran the chgrp command for it:
$ chgrp myGroupName games/
Then, when you run the $ ls -la, you’ll notice that the creator is still listed as your user, but the group is switched to myGroupName. That way everyone in the group will have access to that file. So I copied the Minecraftserver.jar in there and thought that would be it. Since we were planning multiple instances of Minecraft, I also added a folder for this first, vanilla version. The tree looks something like this:
When I ran the minecraftserver.jar so I could edit the EULA, I noticed a problem. The file (even though I had changed its permissions as well) ran as if all the files were being produced by, and for, just my user. This was a problem. I could go back and change it often enough, but that wouldn’t work for times where I wanted the kids to handle things. I needed the new files to have the same group setting.
Setting the GID on the folder
So I emptied out the ‘vanilla_minecraft’ folder and got ready to try again. I made sure all the files had the right permissions, then did one more step on the ‘games’ folder. I set the GID for the folder. This is a handy trick, because it allows all the files created within the directory to inherit that same level of permission for the group use. Here’s the command:
$ chmod g+s /home/games
to make it apply to all subdirectories as well, simply add the -r flag. This way, whenever any group user runs an executable, any files created will be created with the group permissions of the top folder.
This can be a dangerous procedure if you aren’t careful where you apply this type of thinking. It is useful as a shorthand to give a group permission to run files, but you have to be careful what type of files are put in there, and what other things those files touch. I tested it out a couple of times, and was able to create some files in other directories that I didn’t have access to normally because of the group setting. So be careful here, your group needs to know that this is a potential danger on a server, but it’s probably the best balance of security and ease that I was able to strike.
Actually Starting the Server
At this point, I created an open port for the minecraft server, and then ran the server to get the files setup, but that created other problems. I used screen to start the instance the first time, but then realized that we were going to have a problem when the kids tried to attach to that screen, that they weren’t going to be able to. After a bit of searching, I found out that screen wasn’t going to work for what I needed, so I switched over to tmux and found some nifty hackarounds that would work. Namely, creating a specific /tmp folder for the tmux instance and setting its group permissions. This solution, however, was going to be a headache for the kids (it already was taxing me to write out all those commands every time) so I knew what had to be done next. Time for some Bash scripts!