Su AL8 vs AL9 Login Behaviour

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.

And now I can’t get into root at all. Does this OS work at all?

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.

1 Like

Well there must be something odd in your particular setup. On a fairly “bog-standard” system 8.6:

bash-4.4$ su
[root@<hostname> <username>]# exit
bash-4.4$ su -
[root@<hostname> ~]# exit
bash-4.4$ sudo su
[sudo] password for <username>: 
[root@<hostname> <username>]# exit
bash-4.4$ sudo su -
[root@<hostname> ~]# exit

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.

1 Like

Update: Both my /usr/bin/sudo and /usr/bin/su had ownership and permissions gone bad. The fix for su:

sudo chmod 4755 su

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.

Do you know if it’s possible to re-image an OS only on a drive?

The default install creates five filesystems:

  • /
  • /boot
  • /boot/efi
  • swap
  • /home

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.