Any way to restore/repair filesystem? after chmod o-rwx / -R

[st22]

Hi there,

Today during configuration of MusicPlayerDaemon i run "chmod o-rwx / -R" as root instead of "chmod o-rwx . -R". I canceled it but a bit too late. Later i tried the same but with +. Soon i realized there is probably no way to repair what I've done. Is that true? Is reinstall of the system the only way? Can anyone help?


Thanks.
Matt

[einheitlix]

Ouch! Now this is really messed up

Since you changed the permission bits, there is no way to know which permission bits were set before. Hence, there is no way to recover all of this information automatically.

But as you cancelled the command, you might just be able to do it manually. It depends on how many files were changed, and how much work you are willing to invest

You could try something like

Code: Select all

find / \( -path /dev -o -path /tmp \) -prune -o ! -perm /7 -exec ls -ld {} \;

to find all files in / which have no permission bits set for the "others" group, and hence probably fell victim to your command, or are not supposed to have any of these bits set anyway (more accurately, this find command will find all files for which it does NOT hold that any of the permission bits read, write or execute are set for the "others").
Note: I excluded the directories /dev and /tmp, since they are going to give a lot of results and are not relevant anyway, for if I am not mistaken, after a reset the contents of /dev are regenerated and /tmp is emptied.

Then if there's not too many, maybe you could just undo the changes yourself... in most cases you should know which permissions a file is supposed to have.

You could also semi-automate it with more sophisticated find commands, like

Code: Select all

find / \( -path /dev -o -path /tmp \) -prune -o -type d ! -perm /7 -exec chmod o+rx {} \;

...which would narrow down the first find command to only those results found that are directories and execute "chmod o+rx" on each of them. But this might also mislead you into setting some permissions wrong, so pay attention.

I guess you won't get your old system 100% back, but you can probably limit the damage a whole lot and make the system usable again. On the other side, maybe a new install would just be easier... if I was you, I would play around with commands like the above and see what I can do, and if there's just no end to it, I'd probably go for the reinstall.

Good luck!

[st22]

Thanks einheitlix.

Here is how my / looks like:

Code: Select all

drwxr-xrwx 18 root  root   4096 III 12 13:28 .
drwxr-xrwx 18 root  root   4096 III 12 13:28 ..
drwxr-xrwx  2 root  root   4096 II 24 20:33 bin
drwxr-xr-x  4 root  root   1024 III 12 00:19 boot
drwxr-xr-x 17 root  root  14060 III 13 08:20 dev
drwxr-xr-x 46 root  root   4096 III 13  2008 etc
drwxr-xr-x  6 root  root   4096 II  7 13:56 home
drwxr-xr-x  7 root  root   4096 III 11 19:02 lib
drwx---rwx  2 root  root   4096 II 10 16:45 lost+found
drwxr-xr-x  7 root  root   4096 III  2 21:36 mnt
drwxr-xr-x  4 root  root   4096 III  9 14:51 opt
-rw-r--r--  1 gomul gomul     0 III 12 13:28 oy
dr-xr-xr-x 68 root  root      0 III 13  2008 proc
drwx------ 12 root  root   4096 III 12 13:22 root
drwxr-xr-x  2 root  root   4096 II 20 19:52 sbin
drwxr-xr-x 12 root  root      0 III 13  2008 sys
drwxrwxrwt  4 root  root   4096 III 13 08:20 tmp
drwxr-xrwx 14 root  root   4096 II 21 11:13 usr
drwxr-xr-x 12 root  root   4096 II  3 14:18 var

after chmod command i run yesterday. Only /usr and /bin i guess are affected with rwx bits for 'others'. It is because i run chmod o+rwx right after chmod o-rwx. It is, I guess, possible that chmod also changed bit masks of files in other folders form / but i stopped it before it affected any of parent folders (i mean /..). I will try to run your commands today to see if they can help. unfortunately i dont have time to reinstall my whole system.

Thanks again for your help

Matt

[einheitlix]

Oh. I guess I didn't read through your first post carefully enough. I'd forgotten that you also ran a "chmod o+rwx / -R" afterwards. Apparently you cancelled that one too, since not all of your directories are chmodded with all (rwx) permission bits for the "others".

I'm sorry to tell you this, but this probably messed up your system even more. It didn't solve anything, since this doesn't restore the original bits at all, but rather just sets them all to 1 instead of 0. Which doesn't help, rather the opposite. Now you have some files which have "---" for the others (because of your first command), some files which have "rwx" for the others (because of your second command) and, luckily enough, most of your files still seem to have the original permissions. I don't know if chmod always goes through all the files in the same order, because in that case after your 'chmod o+rwx ...' command it would hopefully treat those same files for which you already had changed the permission bits with the 'chmod o-rwx ...' first anyways, so it wouldn't be that bad. Note however, that this is much more of a security risk than having all permission bits for the others set to 0, since now, ANYONE having access to your system can read, change and execute ANYTHING in /usr and in /bin. In fact, to call this a security "risk" is a joke; this is an actual security nightmare

This is what my / looks like:

Code: Select all

drwxr-xr-x 23 root root      648 Mar 10 04:24 ./
drwxr-xr-x 23 root root      648 Mar 10 04:24 ../
drwxr-xr-x  2 root root     2808 Mar 11 13:11 bin/
drwxr-xr-x  3 root root      240 Mar 10 14:01 boot/
drwxr-xr-x  8 root root      240 Mar  1 03:54 data/
drwxr-xr-x 17 root root    14140 Mar 13 07:28 dev/
drwxr-xr-x  3 root root       72 Jan  2  2007 emul/
drwxr-xr-x 77 root root     4768 Mar 13 07:28 etc/
drwxr-xr-x  5 root root      128 Feb 17 02:10 home/
lrwxrwxrwx  1 root root        5 Dec  5 20:50 lib -> lib64/
drwxr-xr-x  3 root root     3584 Mar 10 01:27 lib32/
drwxr-xr-x  8 root root     4968 Mar 10 04:24 lib64/
drwxr-xr-x  8 root root      224 Dec  7 12:16 mnt/
drwxr-xr-x 18 root root      560 Mar 11 14:56 opt/
dr-xr-xr-x 93 root root        0 Mar 10 15:02 proc/
drwx------ 46 root root     3600 Mar 13 02:23 root/
drwxr-xr-x  2 root root     3576 Mar 10 04:24 sbin/
drwxr-xr-x 11 root root        0 Mar 10 15:02 sys/
drwxrwxrwt 14 root root      776 Mar 13 09:12 tmp/
drwxr-xr-x 18 root root      536 Mar 10 13:14 usr/
drwxr-xr-x 14 root root      360 Jan  2  2007 var/

Not only your /usr and /bin seem affected, but also your /lost+found. It should have 700 instead of 707 (but this one you can fix quickly, since it is normally only needed when reparing a partition; so in principle it should be empty, and you can just chmod 700 it and that's it).

Also, your / itself seems affected, although this does surprise me, because I would have thought that it would be chmodded last, after all the rest has been done. However, the first two lines in your 'ls -la /' indicate that your / is set to 707, too (in the special case of /, '/.' and '/..' point to the same inode).

Anyway, the command I provided above isn't probably what you need now (though you could execute it once to be sure), since it finds those files which have NO permission bits in the 'others' column, and you want to find those files which have ALL permission bits in the 'others' column. So we need to change it like this:

Code: Select all

find / \( -path /dev -o -path /tmp \) -prune -o -perm -7 -exec ls -ld {} \;

(replace the '! -perm /7' by '-perm -7'; see 'man find' for details )

Here's another crazy idea: since there are only files in /usr and /bin which were changed, and these are mostly system-only related, why not try to download a stage3 tarball again, and untar the directories bin/ and usr/ from it to /, overwriting your old files (but they should be the same ones), whilst recovering the permission bits? You should use

Code: Select all

tar xvfjp stage3-amd64-*.tar.bz2 bin/ usr/ -C /

for that. The -p ensures that the permission bits from the tarball will be set for all the individual files.
Since you will only overwrite your original system files with this, but not files from packages you installed afterwards, you could also do a

Code: Select all

emerge -e system && emerge -e world

after that. I'm not 100% sure but I think this should also restore the permission bits for the other packages installed (to be absolutely sure, you could even remove, or better yet, backup and remove /usr and /bin first, and execute those two commands - I mean the tar and the emerges - after that, from a live cd of course, since removing these directories will make your system not work anymore). Note that the latter command is going to take a hell of a long time, since you are going to recompile your whole system. It depends a lot on your computer speed, but in average, count 2 or 3 days

After these two commands, you could execute the 'find' command I wrote further above in this post to find all the files which still have all the permission bits set in the 'others' column, and fix these (hopefully few ones) manually. Then you should be ok.

I hope to hear from your success

PS. So to sum it all up, here's what you should do:

1. Boot a live cd
2. Mount your root partition, say to /mnt/gentoo
3. Backup /mnt/gentoo/bin and /mnt/gentoo/usr
4. Remove /mnt/gentoo/bin and /mnt/gentoo/usr
5. Download stage3 tarball and 'tar xvfjp stage3-amd64-*.tar.bz2 bin/ usr/ -C /mnt/gentoo'
6. chroot to /mnt/gentoo (you may want to mount /proc and /dev to /mnt/gentoo first, like explained in http://www.gentoo.org/doc/en/handbook/h ... art1_chap6)
7. emerge -e system && emerge -e world
8. To find the files which are not fixed yet, 'find / \( -path /dev -o -path /tmp \) -prune -o -perm -7 -exec ls -ld {} \;'
9. Fix the remaining victim files (if any) manually
10. Reboot into your system and be happy

[st22]

As soon as I have some free time I'm gonna follow your tips. (I hope during the weekend)

I thought that chmod always goes through the files in the same order. That is why i run + command later. That was because after "chmod o-rwx" all my fonts in web browser turned into squares. I got a bit scared I wasn't thinking.
I dont know if it is like this but:
I run chmod for / and / itself was marked o+rwx where not all his subdirs were. Then it is possible that if /usr and /bin were marked then nothing else was affected if /.
I dont know if it is ok taking it for granted.


Thanks for all

Matt

[einheitlix]

Then it is possible that if /usr and /bin were marked then nothing else was affected

I wouldn't take if for granted. But you can find out that very easily with that find command I provided. Btw, I tried it and noticed that this command returns a lot of symbolic links, which is obvious since symbolic links always have all permissions bits set for all columns (i.e. 777 in octal representation).
So you will want to tune that find command so that it also prunes all symbolic links, like this:

Code: Select all

find / \( -path /dev -o -path /tmp -o -type l \) -prune -o -perm -7 -exec ls -ld {} \; 

That's much better than the first command I told you.
Also, if you want to find out what else has been affected besides /bin and /usr, just prune these dirs too. This simple command will tell you the answer:

Code: Select all

find / \( -path /dev -o -path /tmp -o -path /bin -o -path /usr -o -type l \) -prune -o -perm -7 -exec ls -ld {} \; 

Ok, that should be about it. I can't think of anything more. Have a fun weekend

[st22]

I have just played around with your commands and here's what I've found out:

1. files with o+rwx are placed in /usr, /bin, /list+found and:
drwxrwxrwt 2 root root 4096 II 19 16:31 /var/cache/fonts
drwxrwxrwt 4 root root 4096 III 15 10:27 /var/tmp

Those two last are ok to have such mod, aren't they?

2. files with o-rwx are in:
/proc, /sys /home, few in /rootm /usr /etc and /mnt and /var/lib /var/log
all these are ok i think.

Affected files are mainly in /usr and /bin (also /lost+found)
So maybe it would be good idea to extract those dirs from stage. But that would not solve problem with files that were not in the stage (those added during a usage of the system).

[toralf]

What's about doing an "emerge -e system" ? This should at least install the base system with correct permissions, isn't it ?

[einheitlix]

drwxrwxrwt 2 root root 4096 II 19 16:31 /var/cache/fonts
drwxrwxrwt 4 root root 4096 III 15 10:27 /var/tmp

Those two last are ok to have such mod, aren't they?

Yeah, as you can see they have the sticky bit set (the "t"). The sticky bit is used for temporary directories. These are writable for everybody, which means anyone can modify the directory's entry in the file system. Hence, while user BOB could not modify (i.e. write to) a file in this directory that belongs to EVE (if it is not writable), he could delete (unlink) or rename the file, and put another in place. This would be a serious security flaw, as any user could mess around with another user's temporary files in this directory. So, one sets the sticky bit for such directories, which means that in this directory, only root or the owner of a file can unlink or rename it.

So maybe it would be good idea to extract those dirs from stage. But that would not solve problem with files that were not in the stage (those added during a usage of the system).

Yes, as I said, you should REMOVE these directories first and THEN extract them from the tar archive. Then you're sure that no corrupt files are left, there'll only be a few missing. So then you can regenerate these files in /bin and /usr back by doing an 'emerge -e system && emerge -e world' which will reinstall all packages you have installed, hence regenerating all those files that were added during the usage of the system. Except for those in /usr/local/, this directory you should backup first and copy it back later, and fix it manually, if you ever installed something into it.