View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000203 | AlmaLinux-8 | passwd | public | 2022-03-22 07:40 | 2022-03-23 17:23 |
Reporter | elialum | Assigned To | |||
Priority | urgent | Severity | major | Reproducibility | random |
Status | new | Resolution | open | ||
Platform | Almalinux | OS | Almalinux | OS Version | 8.5 |
Summary | 0000203: User level permissionts/settings randomly destroyed (su: failed to execute /bin/bash: No such file or directory) | ||||
Description | We are getting hit by random system-level user errors in which the user is completely unable to function, nothing basically works, here is one simple example of trying to SU to the user - su username su: failed to execute /bin/bash: No such file or directory As these are mostly users that related to websites, everything is dead obviously (websites, crons, anything) Our quick & dirty workaround currently is to recreate the user - userdel username useradd username chown -R username.username userhomedir One thing we noted is that "nobody" user on this server is different from than usual system: ~>grep nobody /etc/passwd nobody:x:65534:65534:Kernel Overflow User:/:/sbin/nologin usually, it's like ~>grep nobody /etc/passwd nobody:x:99:99:Nobody:/:/sbin/nologin nobody uid=65534, pid=65534 is unusual as far as I can tell? Not sure if it's related though Thanks, Eli. | ||||
Additional Information | Kernel: 4.18.0-348.20.1.el8_5.x86_64 | ||||
Tags | No tags attached. | ||||
abrt_hash | |||||
URL | |||||
|
Hello. Both nobody users are correct but for different os versions. RHEL8: ~>grep nobody /etc/passwd nobody:x:65534:65534:Kernel Overflow User:/:/sbin/nologin RHEL7: ~>grep nobody /etc/passwd nobody:x:99:99:Nobody:/:/sbin/nologin Is it possible that your server OS was attacked or unintentionally damaged by someone? AlmaLinux itself doesn't modify users or their dirs in any way. Does /bin/bash actually present in system? |
|
Hello alukosho, Thank you for your reply, /bin/bash is present in the system. Do you have any clue how can we investigate that issue? |
|
Found the issue, an internal script that runs daily on the users and doing something on their group ownership (security-wise) if some conditions are met. Worked perfectly on COS7, so we didn't catch it initially when upgraded to ALM8 We can close this one |