klightspeed
commented
6 years ago Server admins are part of the serverctl group. They have access to steam's user folder and /srv/ark-server/. They are the users that have permission to change the server core files.
The ARK server changes the permissions on its config files etc. to 0600 (u=rw,go-rwx) on starting, so the script would need to change the permissions back to whatever configured permissions you want.
I'm running the server out of /srv/ark-server, this is where all ark files are installed. It is owned by serv-ark:serverctl. It has the setgid flag (-s-) so that files created in it stay owned by serverctl.
The setgid bit only ensures files are created with the specified group. It does not ensure that the group permission bits are not changed by the file's owner.
As a system user, serv-ark has no home directory. I didn't previously need one, so I'm not sure why ark-server-tools needs it.
The directory the command runs in needs to be accessible, as otherwise some commands have been seen to fail.
I assume steamcmd is used so that updates can be checked for on startup, but it can't do this because serv-ark doesn't have permission to do that. Also, I have autoupdate on start turned off. It also does this on shutdown, which I can see no reason for. With that said, shouldn't it be running as steamcmd_user anyway, based on the config files?
steamcmd_user is currently used when the script is run as root, and to determine whether or not to use sudo when performing a tools upgrade.
The warnings are from sanity checks that are performed during script startup.
If I ran arkmanager as any other user first, the log files can't be updated. It should probably make the files with the same permissions as the log directory.
Non-root users cannot set the owner of files or directories without the CAP_CHOWN capability. The default permissions of the log files are determined by the umask of the running user.
I have to jump hoops just to get serv-ark to run the program because /usr/local/bin isn't in a system user's PATH. That's... minor, but annoying.
https://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/usr.html
Locally installed software must be placed within /usr/local rather than /usr unless it is being installed to replace or upgrade software in /usr.
If you wanted to install the software into /usr/bin, then the install-time --prefix=/usr option can be used. Giving install.sh the --help argument will show what options are available. Such options are also passed through the net installer.
If the script is running a 'server' command, the first thing it does after parsing arguments and loading settings is to immediately fork to the server daemon user and exit. The child arkmanager is no longer assumed to have write access to the core server files, and it does not attempt to change away from the installation directory. It is assumed to have write permission to the log directory. The only sudo permission administrators need is permission to run sudo arkmanager
By server command, I assume you mean commands such as run?
The ARK server (i.e. ShooterGameServer) needs read access to its own files, and write access to its Saved directory. If write access is not granted to e.g. its GameUserSettings.ini file, then RCON commands that set server variables (such as the MOTD) will not persist over restarts.
If -automanagedmods is used, then the ARK server will also run steamcmd installed in its Engine/Binaries/ThirdParty/SteamCMD/Linux directory, and that requires a valid home directory.
PR #971 adds options to set the directory into which arkmanager will switch, and to set the user under which the game server runs.
Tahvohck
Romaq
Context:
steamcontrols access to steamcmd. As much as possible, it is isolated from the rest of the system. This is mostly set up this way because that's how steamcmd suggests it. It does mean that while the command isn't globally installed, it's still "centrally" installed.serv-arkcontrols the ark system and nothing else. As much as possible, it is isolated from the rest of the system. For security reasons, it is not even able to update the server itself.serverctlgroup. They have access tosteam's user folder and/srv/ark-server/. They are the users that have permission to change the server core files./srv/ark-server, this is where all ark files are installed. It is owned byserv-ark:serverctl. It has the setgid flag (-s-) so that files created in it stay owned byserverctl.When managing things manually, this worked pretty well. Server admins updated the game, then started a systemd unit file that started the server, switching to
serv-ark:serverctland setting the working directory in the process. The only permission they needed was to start the unit file (a specific line in sudoers). The server is never run as a user with more permissions than it needs, and it can't interact with any other steam servers I run.With ark-server-tools, I'm having problems getting this setup to work. If I run the command as
serv-arkthis happens:Start runs basically the same, but status gives a good example. There are a couple of issues I'm hitting here.
serv-arkhas no home directory. I didn't previously need one, so I'm not sure why ark-server-tools needs it.serv-arkdoesn't have permission to do that. Also, I have autoupdate on start turned off. It also does this on shutdown, which I can see no reason for. With that said, shouldn't it be running assteamcmd_useranyway, based on the config files?arkmanageras any other user first, the log files can't be updated. It should probably make the files with the same permissions as the log directory.serv-arkto run the program because/usr/local/binisn't in a system user's PATH. That's... minor, but annoying.If I run the server as a member of
serverctl, because they have permission to run steamcmd everything seems to work fine. This is basically the same as current "intended" usage. The only problem is that the server is then run as them. If another administrator were to log in, they wouldn't be able to meaningfully interact with the server. They can't stop it, status returns incorrect information, they can't even start their own server because the port is bound already.Thankfully, writing this up allowed me to rubber-duck the situation, so any of the other problems are eliminated. It's also gotten pretty long, so I apologize if it's rambling. With that said, I propose the following changes to operation:
arkmanager, you have the right permissions to runsteamcmd.sh.steam, but still configurable. In single-user installations it's defaulted to the installing user (--mesyntax should still work here)arkmanageris no longer assumed to have write access to the core server files, and it does not attempt to change away from the installation directory. It is assumed to have write permission to the log directory. The only sudo permission administrators need is permission to runsudo arkmanagerUnder this flow, a user running the server as themselves would notice no change.
sudoto yourself is allowed without any configuration, and the script continues as normal. Users running the server in a restricted sandbox would still be able to configure the server, download updates, and set up cron jobs, but would run the server itself as the sandboxed user.