Not sure how this has happened but some directories in my home directory have been “chowned” to user nobody (group nobody). And on trying sudo to get into them it doesn’t work because all of the directories in the root folder have been “chowned” to user nobody (group nobody).
I’m surprised and surprised that the system is even running like this. Maybe systemd can run things whatever their permissions or maybe this machine will not reboot, in which case I should post in the forum for boot problems. On installation I did create another log-in with “admin” privileges, but before I try anything for such a widespread problem does anyone have any thoughts? (I did run a find command from root with the -prune option; I don’t know that option well but I don’t see that find without an -exec command could have done this). I can’t get into the directories in /var/log/ but I do not see a directory for rkhunter which I thought was there…
This has probably broken root access. To fix it, you will need to boot rescue media, mount your file systems, and then use “chown” to fix the ownership.
Hi
I guess I could chown everything in var and all sub directories with
/# chown -R root: var
or should that be chown -hR?
But firstly
Can you say if everything other than the users home directories is usually owned by root so that I could do the same with each of the directories in the root directory? Once I have booted into the rescue system I could step into each sub-directory to look but even so I could easily miss one and I don’t know if I could work out some way of listing directories not owned by root.
And secondly
I used the option of LVM when I installed so could you point me to how to mount var and each directory from the rescue system please?
Thanks
No, that is not the case. And that is the big problem here. When I remember correctly there is a tool that is able to set ownership (by uid and gid) and permissions of installed files to what they were set to at installation (information extracted from the RPM). But all others?
Hi Henk
Big problem indeed. If you have any info on that tool I would appreciate it.
P.S. Right now I am inclined to blame firejail for this. All of the directories in my home directory which were altered have the timestamp Nov 3 09:01
although this is not the case for those in the root directory. At that time I was struggling with firejail and Firefox, so it could have been Mozilla to be fair…
Hmmm… I very seldom make such comments, but… I think I’d place the blame elsewhere 
…
Might be easier to just re-install, keeping your existing home directory.
I concur. As long as you do not run Firefox as root, it can not change anything in the “system” directories.
I concur again.
If you want to learn stuff and feel bored, you can also waste some time trying to fix the permissions by:
- Get a Rescue system
- Boot Rescue and mount your existing installation and chroot into it.
- Run;
rpm -qa --qf "%{NAME}
" | xargs rpm --restore
And drink a cup of coffee while you wait. Reboot once done.
OK, that seems to be the one I hinted at (thanks). But be aware that it will not change anything on files that are created outside installation processes. E.g. many configuration files.
Thanks for that :|. It has taken a lot of tweaking to get this system working like it was (well is at the minute, probably until I shut it down tonight… only thing other than firejail which isn’t perfect is that Konsole lists all files and directories without any colour). So I also don’t want to speculate on how it happened so as not to distract any other suggestions about how I might rescue my system.
But it is strange that in my home directory only hidden files/directories are affected; the files are all empty (some of them relate to apps I don’t use like .emacs). The directories are .gnupg, .java, .mozilla and .pki and I think thats all. Can’t see what happened in the other users home directory but all of the directories in the root folder seem to be affected (but there the time-stamp is not uniformly altered). I did use the bash shell in console (at root folder) after there was a warning “Warning: an existing sandbox was detected. /bin/bash will run without any additional sandboxing features”. But I only used it after shutting down the problem process to get
“Parent received signal 15, shutting down the child process…
Child received signal 15, shutting down the sandbox…
exit”
Just put that there for anyone for whom it means anything, Any further help would be welcomed.
Thanks Henk and Miuku. I think I might try that over the weekend.
P.S I might need some help on mounting an LVM system, I am indeed still learning.:shame:
Out of curiosity; did you try to su to root or login as root rather than sudo?
Open bash; **su **and enter root password.
Then run the aforementioned command.
Ceterum Censeo: Alway use
su -
and not
su
If all else fails - there is single user mode. It gives root access to everything. I have recovered systems with single user mode.
Here is a tutorial on single user - it is the same in openSUSE as well.
https://tekneed.com/boot-to-single-user-mode-in-linux-rhel-centos-78/
It doesn’t seem to matter either way
su -
bash: /usr/bin/su: Permission denied
But maybe I will have to re-install…
/usr/bin> file su
su: empty
/usr/bin> ls -l su
-r-------- 1 nobody nobody 0 Nov 3 09:01 su
Thanks for that. I haven’t booted into single user mode since grub legacy, I didn’t even know it was still possible. I have saved the link in a test file.
It is a bit of topic (but when I see this potential break of security, I will throw my “ceterum censeo” in).
That you do not see the difference at this moment in time does not mean that it is a matter of no importance.
OTOH, when I remember correctly, they changed the behaviour of su a year or so ago, just to avoid noobs using the wrong command. Have to read the man page again.
It might indeed be that using single user mode is easier then a rescue system.
If system is compromised, you are still working inside compromised system in single user mode. Booting from (read-only) medium gives you known good state.