-
-
Notifications
You must be signed in to change notification settings - Fork 144
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Steam user not correctly set, multiple administrators not possible #969
Comments
The ARK server changes the permissions on its config files etc. to 0600 (
The
The directory the command runs in needs to be accessible, as otherwise some commands have been seen to fail.
The warnings are from sanity checks that are performed during script startup.
Non-root users cannot set the owner of files or directories without the
https://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/usr.html
If you wanted to install the software into
By The ARK server (i.e. ShooterGameServer) needs read access to its own files, and write access to its If PR #971 adds options to set the directory into which |
I think that PR #971 will solve the major issues I was having. The big reason I opened an issue instead of trying to tweak the code myself was the assumption you knew the code better and knew a more efficient way to solve it. I'm glad that was the case. :P
|
I have a setup that has me happy having cluster files saved to /home/steam/copper (the cluster name). My intent is to allow *.ark to be read by a trusted user so he can skim the latest copy of the *.ark file for use with Ark Smart Breeding. Unfortunately, I have the following problem with the group permissions: -rw------- 1 steam steam 48M Mar 6 07:13 Ragnarok.ark The only reason "TheIsland.ark" isn't set g-rw yet is the instance hasn't saved to that copy coming from my Windows machine FTP backup. Once the new TheIsland.ark is written, I'll lose it to go-rw. "The default permissions of the log files are determined by the umask of the running user." is mentioned in this thread. "$touch test" by user steam gets me the expected -rw-rw-r-- permissions. So "somewhere" the umask is being changed. How may I have "umask u=rw,g=r,o=" for *.ark file writing? My hope is to add my friend to the steam group, allow him to read the data via sftp, and neither one of us have to worry about potential harm to the *.ark data. |
The From a strace I did a while ago:
The first line shows the server creating the new temporary file with mode In this, TID 29240 is a thread within the server process:
The server also sets mode 0600 when writing a new profile or tribe file.
The important bits are:
|
UGH! I was afraid of that. Time for yet another nasty-gram to the Ark Devs that make this crap up. I'm installing the Valheim server without even purchasing the game just to see how it goes. I love the work you are doing here, it's important work for us to be enjoying Ark on a LAN Linux host. But you shouldn't have to do this, or as much of it. Ark server should have been better written, and "clustering" shouldn't even be a 'thing' except very special "dragons be here" circumstances. Thanks for the response, we'll live with access to the steam user because it's the path of least resistance. Making a sticky-bit script to chown the file isn't on my list of things to do. >:( |
Context:
steam
controls 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-ark
controls 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.serverctl
group. 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:serverctl
and 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-ark
this happens:Start runs basically the same, but status gives a good example. There are a couple of issues I'm hitting here.
serv-ark
has no home directory. I didn't previously need one, so I'm not sure why ark-server-tools needs it.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 assteamcmd_user
anyway, based on the config files?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.serv-ark
to run the program because/usr/local/bin
isn'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 (--me
syntax should still work here)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 runsudo arkmanager
Under this flow, a user running the server as themselves would notice no change.
sudo
to 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.The text was updated successfully, but these errors were encountered: