Just wondering why the behaviour of su on AL8 behaves poorly where on AL9 works as expected.
AL8 requires me to use sudo su to get into root. su comes up with su: cannot set groups: Operation not permitted. And when I do get into root, ~/.bash_aliases will not be sourced for some reason.
In AL9 I have in my root’s ~/.bash_profile, I have source /home/myuser/.bash_aliases but it does not load. I tested with some quick aliases. Neither load properly.
Seeing differences between these two versions of AL has me questioning if this is a RHEL issue or an AL issue.
Does anybody have any insight into this? I’d like to get root loading what I thought were its login files.
Quite many people have used in many many machines for several months now, so the answer to that is: “Yes, it does work.”
The concept of sourcing some regular account’s files into root’s profile is outright scary.
You have probably done such “customizations” in both platforms. They can very well
be the reason for the behaviour that you do observe.
Well there must be something odd in your particular setup. On a fairly “bog-standard” system 8.6:
bash-4.4$ su
Password:
[root@<hostname> <username>]# exit
exit
bash-4.4$ su -
Password:
[root@<hostname> ~]# exit
logout
bash-4.4$ sudo su
[sudo] password for <username>:
[root@<hostname> <username>]# exit
exit
bash-4.4$ sudo su -
[root@<hostname> ~]# exit
logout
bash-4.4$
So both su and su - (the latter being preferable) work as expected and demand the root password. Prefixing with sudo requests my password first time, again as expected. I then went to my AL9 test machine, and repeated the same tests, with exactly the same results.
I would echo @jlehtone 's second paragraph, sourcing user configuration files into root is not best practice. My suggestion would be to clear out the modified root startup files and ensure that the system is behaving as expected. Then, and only then, start to add such aliases as root will actually need explicitly into root’s startup files. After each change, test fully!
If you really can’t get into root at all, you may have to use the emergency bootstrap option from the boot menu.
wow, with such permissions gone bad, I suggest you reimage that server. Those permissions are not changed by themselfs and who or what did it might still be around.
All user data, except account info (which is in /etc/) and mail spools are on the /home volume.
It should be safe to reformat the first four volumes and merely mount the existing /home on (re)install. Then recreate regular accounts.