[youssefbasha]

your vps name?:VPS 18
which node are you?: Idk
whats your issue?:
I was installing pterodactyl from the documentation and the last step before that error happenes is enabling SElinux (already in the documentation) and in the tutorial they said i have to reboot the server to take the effect.
I rebooted and got this 
Do you have any idea on what happened?

[Mashiro]

This happens right after you login? You are able to login and actually run commands? Just asking to set some things straight and clear from the beginning. Which OS are you using by the way? Can you provide a link to the documentary of the software you installed?

[youssefbasha]

This happens right after you login? You are able to login and actually run commands? Just asking to set some things straight and clear from the beginning. Which OS are you using by the way? Can you provide a link to the documentary of the software you installed?

I login, cant type any command and it automatically close after 5 seconds or something
Im using CentOS 7.6
Documentation link: https://pterodactyl.io/community/install...y-pakcages

[Mashiro]

Thank you for providing all requested information. Am I right with my statement if I say that you have no real access to your server anymore. You cannot even perform emergency repair?

From the looks of it access to he default shell of the user is no longer possible. The reasons for this can be various, startin from incorrect permission for /bin/bash to a misconfiguration of SELinux which has turned it very overprotective.

If you really have no other way to access the server a staff member has to look into the issue. I see the VPS has no control panel. So a staff has to look into the issue. If I would be somehow able to get temporary access I would try to look into the issue.

@Dynamo @deanhills @perryoo11

[youssefbasha]

I dont have any problem if you got temporary access from deanhills or Pacific.

[deanhills]

@"Hidden Refuge" - temporary access has been provided.  If you can help with Youssefbasha's VPS that will be much appreciated.

We'll be grateful if you could report on the outcome here.  So far @youssefbasha is the only, and I mean the only member who has had issues with access to a Hostlease VPS.  Your expert input as to the reason of the problem, will be much appreciated.

[Mashiro]

@deanhills thanks a lot! Hopefully I can find the reason and a fix for it. I will report back once I have looked into the issue and found a solution.

@youssefbasha I would require your root password to access the VPS. Please send me a private message. Otherwise I cannot really continue.

[youssefbasha]

Sent ✓
Hope you can find the solution
I didn't do anything wrong as i see xd

[Mashiro]

Here is my report after getting all necessary information to took a look at the VPS from the available emergency console/VNC.

Basically it is exactly as I said before. The user(s) can no longer access their default shell. When you login as a user a shell is started for that user. The reason for that from your previous error message with "/bin/bash: permission denied" is that either the permission for /bin/bash is incorrectly or SELinux is being very overprotective (most likely the case as this started happening after you enabled SELinux and rebooted your server).

The bad news: login from the normal Linux TTY is also not possible! You instantly get logged off because the shell cannot be started. It's basically a loop. You type in your username and password, you are logged in for a very brief tiny moment and land at the login screen again. Everytime! That's a big mess right there! And maybe another bad news: you cannot even boot into the rescue mode of CentOS 7 because the exact same issue happens there. The rescue shell uses sh instead of bash and we're getting a "/bin/sh: permission denied" and it continues to boot into normal mode after a few seconds.

So the internal rescue mode of CentOS is useless, too. Thankfully there was a CentOS 8 ISO available. I mounted it and restarted the VPS. In the CentOS 8 ISO bootloader I could select a option to run a system rescue mode. The rescue mode mounts the installed CentOS into /mnt/sysimage and from there on you can access all files through the rescue sh shell of CentOS 8. I edited /etc/selinux/config (/mnt/sysimage/etc/selinux/config) and set SELINUX to disabled. I saved the file and rebooted the VPS. It started from the installed CentOS 7 and I could login normally in the Linux TTY and also in SSH.

That's about it. SELinux was overly protective and broke pretty much the whole system. To be honest: SELinux is cancer. Not only that NSA was working on it but it's kinda not helpful at all.

Your VPS is working again.

[fChk]

(...)

So the internal rescue mode of CentOS is useless, too. Thankfully there was a CentOS 8 ISO available. I mounted it and restarted the VPS. In the CentOS 8 ISO bootloader I could select a option to run a system rescue mode. The rescue mode mounts the installed CentOS into /mnt/sysimage and from there on you can access all files through the rescue sh shell of CentOS 8. I edited /etc/selinux/config (/mnt/sysimage/etc/selinux/config) and set SELINUX to disabled. I saved the file and rebooted the VPS. It started from the installed CentOS 7 and I could login normally in the Linux TTY and also in SSH.

That's about it. SELinux was overly protective and broke pretty much the whole system. To be honest: SELinux is cancer. Not only that NSA was working on it but it's kinda not helpful at all.

Your VPS is working again.

Well done @Hidden_Refuge !.. Although I would have just set SELinux to 'permissive' instead of its default 'enforcing' mode in CentOS.

My course of action would have been: setting SELinux on its permissive mode then reboot to CentOS 7 then troubleshoot the SELinux problem. When I'm sure that the issue is resolved, ie no more throwing of AVC (Access Vector Cache) messages in the logs, only then I would re-enable SELinux.

It's indeed more work but I think It's the advisable way to deal with SELinux headaches; disabling it altogether is throwing away one of the best CentOS/RHEL/Fedora line of defenses against privilege escalation attacks (especially for a 24/7 online system.)

Generally the problem is solved by just re-Labelling system files by their correct SELinux context. It's done (on Fedora) by running:

Code: (Select All)

sudo fixfiles -F onboot
reboot

It should be the same on CentOS; Fedora being the bleeding edge of RedHat systems (RHEL and CentOS.)

If the above doesn't fix the problem, then it's generally because the sysadmin is running a process outside of it's normal/default context/location, in which case he should set the adhoc SELinux context for the process to run properly.

Granted, SELinux for those who aren't familiar with is a PAIN.. but once you get the hang of it, it should be OK. I still remember when Fedora first enabled it by default 10 years ago (or so), it was a mess (just like you described above.) Nothing seems to work any more, and people (including myself) start turning that thing off right off the bat (again, just like you did)... But that was wrong... and still is.


---------
PS: Some quick references for our folks in here:
> Basic SELinux Troubleshooting in CLI
> Troubleshooting SELinux
> SELinux/Troubleshooting Wiki
> Troubleshooting SELinux Docs