I don't think this is ISPConfig's fault, but something has changed in AlmaLinux 8.7 (and presumably other RHEL clones like Rocky Linux, Oracle Linux when they are released) and it has affected the way shell users work. I need help to track down what is causing this please. Expected Behaviour Before updating to 8.7 if you logged in as a shell user, you would get the shell username in the bash PS1 prompt, and scripts and cron tasks executed would be run as the shell user, not the webXX user. Actual Behaviour Now, after updating, if you log in as the shell user you receive a bash prompt displaying the webXX username instead, and all processes previously executed as the shell user instead run as the webXX user, including cron tasks. Symptoms Rootless container permissions are all messed up. Rootless containers rely on the subuid system and allocations defined in /etc/subuid. Files, volumes and storages that need to be available in a rootless container must be owned by the correct subuid in the range allocated to the parent userid. However the container is now attempting to run as the webXX user, not the shell user. The webXX user has a different subuid allocation to the shell user in /etc/subuid and therefore cannot access any volumes and storage layers created by the container when it previously ran under a different user. This gives plenty of permission denied type errors and the container fails to start. In addition as the shell user is now not available, it's not even possible to delete and recreate these files without root privileges. Our levels of "suspicious activity" are off the charts as our automated monitoring has detected that users are suddenly running completely "novel" processes, even though this is normal behaviour, the user has just changed. We are also having problems with systemd --user being unable to find unit files, I think that's because the home directory (and therefore the location of user unit files) is different because the user is different. Further Information You don't need to reboot to get this new behaviour, so it's probably not the kernel update. It seems to be related to the order of users in /etc/passwd. Normally the webXX user comes before the shell user in /etc/passwd because a site must be created before the shell user. If I swap the order of the users so that the shell user comes first, then I get the correct bash prompt again, however the container and systemd stuff above is still broken. So it seems like suddenly the order of /etc/passwd matters. However it shouldn't, as all the webXX users have /bin/false as their shell, so login as webXX shouldn't be possible.
Shell users of a website are basically an alias for the webxx user, they share the same UID. This is necessary to give the shell user of the site full access to the files of that site. Crons are always running as webxx user. On ISPConfig's side, there were no changes related to this, we use it in this way for about 15 years now. If behavior on your system changed, it is likely that this is related to changes in the underlying OS. But in the end, the shell users of the site are the webxxx user, they are just aliases used for login via sshd as webxx user.
I agree, as I mentioned at the start of my first message, I don't think this is ISPConfig's fault as it only occurred when updating the OS. However I think user aliases are not widely used and so this strange change of behaviour might not be picked up elsewhere. Also as this is the ISPConfig forum, and everyone here IS using user aliases, I'm more likely to be able to find someone experiencing the same issue. I was able to confirm that the reason systemd user units are not working is because systemd is using the home directory of the webXX user not the shell user: Code: [web147@server ~]$ echo $HOME /var/www/clients/client1/web147/home/username Vs: Code: [web147@server ~]$ systemctl --user show-environment HOME=/var/www/clients/client1/web147 That means the new location for systemd user units is: Code: /var/www/clients/client1/web147/.config/systemd/user/ Instead of: Code: /var/www/clients/client1/web147/home/username/.config/systemd/user/ Unfortunately that location is not writeable: Code: [web147@server ~]$ mkdir -p /var/www/clients/client1/web147/.config/systemd/user/ mkdir: cannot create directory ‘/var/www/clients/client1/web147/.config’: Operation not permitted Even as root: Code: [root@server ~]$ mkdir -p /var/www/clients/client1/web147/.config/systemd/user/ mkdir: cannot create directory ‘/var/www/clients/client1/web147/.config’: Operation not permitted That's because the webXX home directory is immutable: Code: [root@server ~]$ lsattr -d /var/www/clients/client1/web147/ ----i---------e----- /var/www/clients/client1/web147/ So I could make it mutable, create the .config directory and make it immutable again, but that seems like a hack. Really systemd should respect the correct home directory of the logged in user. There should be no mismatch.
