Linuxgsm: RUST & some other games - wrong permissions on /sys = crash on boot

[UltimateByte]

Symptom: the game server just stops while loading after Initializing 74 stability supports

Update3: It's actually not a kernel itself issue, but rather an issue because of permissions on /sys

Fix thanks @cedarlug :
(with elevated privileges)
bash chmod a+rx /sys /sys/class /sys/class/net

[cedarlug]

Details? Link?

[UltimateByte]

You're right, main post edited.
Was just a reminder in the first place.

[dgibbs64]

Ohhhh Garry not again...

[UltimateByte]

@Edou68FR Kernel info ? Distro ? Logs outputs ? ./rustserver postdetails output ?
Without this, we can't really go further into it.

[UltimateByte]

Thanks. Script logs are not useful there though, since this is not an LGSM issue but rather Rust itself.
So game logs output would be more useful. Watch out for your rcon password that may be displayed several times in it.

[UltimateByte]

Thanks.
Well, it crashes right at the same place than MattiEXC from discord.
Initializing 74 stability supports (Filename: /home/builduser/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42)

For now the only clue I got is the kernel that differs. Since I couldn't find a good working tutorial on how to revert to the default kernel, I can't even point you out to this for testing.

Maybe @cedarlug , our Sherlock Holmes got an idea ?

[UltimateByte]

Just called OVH talking about the issue.

I'm quoting, but this is me summing up what they said:

"Some machines had issues with the default kernel, that's why it's been removed. We cannot add all functionalities to OVH kernels. Also, we don't support software. So if you point out an issue with an existing functionality, then we can fix it. But otherwise, it's up to the user to add what they need to their kernel and recompile it."

So any kernel expert is welcome to help... Unless we figure out the issue comes from somewhere else.

[Xseba360]

I recommend updating to latest ovh kernel from their FTP as it seems to work for me 👍

[Elioby]

What kernel are you running as lastest? I'm running latest production 3.14.32

[UltimateByte]

From discord:

Xseba360 - Yesterday at 2:37 PM
interesting, on ovh kernel 4.8.15-xxxx-grs-ipv6-64 the rust server doesnt seem to be starting

[Xseba360]

@UltimateByte, disregard that, it just took longer than I'm used to with source servers, however console i/o isn't working? (Is it supposed to?).

So in conclusion, latest experimental should work. But as the name suggest it's up to you ;)

[cedarlug]

@Xseba360 The Rust console isn't functional in Linux, other than this: "If the console hasn't closed, then the Rust server hasn't died."

Glad that the new kernel worked for you.

[UltimateByte]

We could add a warning upon server start if faulty kernel is detected. There is already a function for machine requirements.

[Xseba360]

http://help.ovh.com/KernelInstall

[TNTUP]

Same here, https://hastebin.com/obajiboqok

EDIT: Multiple attemps, I give up. Thinking of updating the kernel, but im lazy as f* to do it and rebooting :/

[UltimateByte]

Update:
Cedar's fix is enough to fix the issue !

chmod a+x /sys chmod a+rx /sys/class chmod a+r /sys/class/net

I'd even add that chmod a+rx /sys/class/net would even be better if we want to match a sane default Debian install.

[braunsonm]

Not much that can be done about this on LGSM's end. The most that can maybe be done is for LGSM to run a check and prompt the user about the permission issue.
If necessary I will do that. @UltimateByte

[UltimateByte]

I'll do it, tonight, thanks @ChaosMTA , I'm kinda committed to fix Rust for the end of my life, lol.
I'll ask @dgibbs64 , but I think i'll add it to fix_rust.sh
https://github.com/GameServerManagers/LinuxGSM/blob/master/lgsm/functions/fix_rust.sh

Algorithm idea is:
Check 3 dirs for right permissions
if any permission is wrong, check if sudo is available and attempt to fix
if not fixed, display error with commands to run as root
core_exit.sh

[UltimateByte]

Since I forgot to ask where to put this check (either in check_permissions.sh since it's been reported to affect other games as well, or fix_rust.sh), i'll add my code here. This is 100% untested, yet, so this might not be perfect.

````bash

Check if user is sudoer; if he is, value should be greater than 0

issudoer="$(sudo -n uptime 2>&1|grep "load"|wc -l)"

Checks for permission errors in /sys directory

fn_sys_perm_errors(){
# Reset test variables
sysdirpermerror="0"
classdirpermerror="0"
netdirpermerror="0"
# Check permissions
if [ ! -r "/sys" ]||[ ! -x "/sys" ]; then
sysdirpermerror="1"
fi
if [ ! -r "/sys/class" ]||[ ! -x "/sys/class" ]; then
classdirpermerror="1"
if [ ! -r "/sys/class/net" ]||[ ! -x "sys/class/net" ]; then
netdirpermerror="1"
fi
}

Displays /sys related permission errors to the user

fn_sys_perm_error_display(){
# /sys, /sys/class and /sys/class/net should be readable & executable
# If any error was found
if [ "${sysdirpermerror}" == "1" ]||[ "${classdirpermerror}" == "1" ]||[ "${netdirpermerror}" == "1" ]; then
fn_print_error_nl "Permission error(s) found:"
fn_script_log_error "Permission error(s) found:"
if [ "${sysdirpermerror}" == "1" ]; then
echo " * /sys permissions are $(stat -c %a /sys) instead of expected 555"
fn_script_log "/sys permissions are $(stat -c %a /sys) instead of expected 555"
fi
if [ "${classdirpermerror}" == "1" ]; then
echo " * /sys/class permissions are $(stat -c %a /sys/class) instead of expected 755"
fn_script_log "/sys/class permissions are $(stat -c %a /sys/class) instead of expected 755"
fi
if [ "${netdirpermerror}" == "1" ]; then
echo " * /sys/class/net permissions are $(stat -c %a /sys/class) instead of expected 755"
fn_script_log "/sys/class/net permissions are $(stat -c %a /sys/class) instead of expected 755"
fi
echo ""
fn_print_information_nl "This error causes servers to fail starting properly"
fn_script_log_info "This error causes servers to fail starting properly."
}

Attempt to fix /sys related permission errors if sudo is available, exits otherwise

fn_fix_sys_perm_errors(){
if [ "${sudoer}" -lt "0" ]; then
fn_print_information_nl "Automatically fixing permissions"
fn_script_log_info "Automatically fixing permissions."
if [ "${sysdirpermerror}" == "1" ]; then
sudo chmod a+rx "/sys"
fi
if [ "${classdirpermerror}" == "1" ]; then
sudo chmod a+rx "/sys/class"
fi
if [ "${netdirpermerror}" == "1" ]; then
sudo a+rx "/sys/class/net"
fi
else
fn_fix_sys_perm_manually_msg
fi
# Run check again to see if it's fixed
fn_sys_perm_errors
if [ "${sysdirpermerror}" == "1" ]||[ "${classdirpermerror}" == "1" ]||[ "${netdirpermerror}" == "1" ]; then
fn_print_error "Could not fix permissions"
fn_script_log_error "Could not fix permissions."
fn_fix_sys_perm_manually_msg
else
fn_print_ok "Automatically fixing permissions"
fi
}

fn_fix_sys_perm_manually_msg(){
echo ""
fn_print_information_nl "To fix this issue, run this command as root:"
fn_script_log_info "To fix this issue, run this command as root:"
echo " * chmod a+rx /sys /sys/class /sys/class/net"
fn_script_log "chmod a+rx /sys /sys/class /sys/class/net"
core_exit.sh
}

Permission errors on /sys directories

fn_sys_perm_errors
fn_sys_perm_error_display
fn_fix_sys_perm_errors
````

[cedarlug]

I'm skeptical regarding the sudo check for a couple of reasons:
issudoer="$(sudo -n uptime 2>&1|grep "load"|wc -l)"
First, this is asking for a no-password sudo, which is rare for a sudoer. And would incorrectly fail if she has sudo privileges but requires a password.

Second, if the user doesn't have any sudo privileges, this drops an alert in the system logs as a failed user privilege escalation attempt.

As far as I know, the only "safe" way to check to see if a user has sudo permissions is sudo --list. Without a password, it would be sudo -n --list. In either case, if a user does not have sudo privileges this does not drop an alert in the system logs.

Consider using the check sudo --list and requiring the user to enter her password.

[UltimateByte]

Interesting thoughts.
I checked there in the meantime.
https://github.com/GameServerManagers/LinuxGSM/blob/master/lgsm/functions/check_deps.sh#L83
bash sudo -v > /dev/null 2>&1 if [ $? -eq 0 ]; then ...
In the end, it just checks if sudo is installed. Maybe it's the way to go?

[braunsonm]

Should note that I've heard from people in discord that this issue also affects CS:GO servers. Might be something we should just do as an LGSM pre_req test for all servers.

[UltimateByte]

Yep.
One question though, would make this code a bit more simple:
Does any distro have /sys/class/net dirs?
I know debian/ubuntu/centos do have it, don't know for others.

Current work here
https://github.com/GameServerManagers/LinuxGSM/blob/feature/ultimatebyte-271/lgsm/functions/check_permissions.sh

[UltimateByte]

Sample output with & without sudo access:

[UltimateByte]

Warning and autofix if sudo is available: merged to master.

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.