Running as root - potential fixes

[tahosa]

Hello! Now that update 5 and dedicated servers have moved to the early access branch, I'm working on setting something up for me and my friends to play and would like to revive some of the discussion from #44 and other issues with permissions when the container doesn't run as root.

Before I run this on my own docker host, I definitely want to be able to run it as a non-privileged user instead of as root. I'm still experimenting with building and running the current version on the main branch and comparing behavior on the old branch, but wanted to make sure I understand the previous issues as best I can so I can open a PR that solves the issues to everyone's satisfaction. From what I saw, the problems generally fall into several categories:

1. Running the container without volume binding the /config directory to the host causes errors when the internal steam user went to do anything
2. Running the container with volume bindings to non-local devices (e.g. NFS) - errors on running the init script which could be worked around, but other issues when trying to start the server
3. Inconsistency when folders already exist inside /config when container or server is started

Is this an accurate grouping of the problems, or are any missing from previous issues that I have overlooked?

The interplay between permissions during build, what permissions are on the host, potential restrictions with remote volumes like NFS, and the internal filesystem within the container are a nasty problem that I have had to solve before for other containerized servers so I'd love to be able to help solve this security issue if I can. It's entirely possible that this can also be solved entirely without needing functional changes, but it would require users to carefully inspect permissions on their host (and NFS if relevant) before running the container.

[tahosa]

After doing some experimentation, I have been able to replicate most of these scenarios and have a potential cause for the permissions problems. The dedicated server seems to be hard-coded (or at least there isn't a documented override) to put the save files in $HOME/.config/Epic/FactoryGame/Saved/SaveGames. Has overriding the value of $HOME in the environment been tried as a solution to this? If we can get the game to write everything into the default /config folder, it makes it much easier to ensure that the user ID of the container processes matches the host's file permissions.

The current solution to update the UID/GID of the steam user was definitely one way of doing this, but keeps this requirement around the home directory albeit indirectly. The extra soft linking in older versions seems to have been an attempt at partially solving this, but I'm going to now do some more testing with this hypothesis.

[tahosa]

After further experiments, steamcmd is not a very Unix-friendly system. It very much requires a home directory to be set correctly, and permissions on files all over that homedir to be set very particularly. It also doesn't return very useful error messages or return codes, so more work will be needed to potentially work around this. I'm going to continue poking at it to see what can be done that would allow for non-root use in a sensible way.

[wolveix]

@tahosa yes, I made most of your discoveries along the way and documented most of it throughout a myriad of issues. Unfortunately, the server does hardcode a few things, and there's no conceivable route around these limitations aside from what has already been implemented.