I messed up file permissions

I goofed and messed up file permissions for everything under /bin/.
I was logged in as root and did chmod with the -R param, now every file is executable. How can I restore this?

Not to state the obvious, but this is a prime example of why you should ALWAYS use the root account with extreme caution, and even then, only in a small number of specific situations, such as if you are installing new software packages. If you are frequently run as root, or run as root as a matter of habit, it is trivially easy to hose your system.

In any case, without knowing which distro you are running, the generic, safe recommendation I can offer consists of 2 steps:

1. Backup your important data
2. Reinstall

I will defer to people with greater knowledge, but once you change a file(s) permissions, you lose the ability to restore them to their previous value. Thus, a reinstall is the only sure way to return them to their appropriate values. Again, I'll emphasize that others here at LQ may have superior experience and may be able to offer alternative suggestions, but if I were in your shoes I would just go for the reinstall. -- J.W.

thx for the reply. I knew i shouldn't have been goofing around in root. I had heard it, and now I have learned the hard way. I suppose a reinstall wouldn't be so bad. I don't have much configured yet anyway.

I'll wait another day or so to see if any repies come.

If it's any comfort, I'm pretty sure *everyone* learns this lesson the hard way sooner or later. Certainly I fully admit that I did..... and probably more than once... -- J.W.

Why is this a problem?

Isn't /bin full of executables and symlinks anyway?

A chmod -R 755 will restore all normal file permissions and changing all symlinks to 777 will bring him back to normal. Yes or no?

Looking over my /bin Franklin seems to be correct. Just chmod 755 your /bin. Going by memory here, but the file permissons cannot be changed on a symbolic link, it should be 777.

Kristijan

Thanks, but I already reinstalled. Not a big deal. It actually is helpin me learn.

I was under the impression that chmod -r ugo-x /whateveryouscrewedup would revoke executable permissions for those files. But then again, my linux knowlege dosen't warrant a moderator position on a major forum. =)

Travers, you are correct, however, that action would also revoke executable permission on files that were executable before the change. Making all files in /bin unexecutable would cause some rather major system problems.

Everything you use on a linux system is in /bin /usr/bin /sbin and the like. If you chmod -x it, you revoke execution on everything. Unfortunately, this is very bad, condsidering bash itself lies in /bin/bash. You'll render all utilities virtually useless including ls, cp, mv, bash, sh, tcsh, etc.. etc... and the really bad thing is, you won't even be able to change it back, because chmod is a program that lies (guess where), hence rendering it useless as well.

As btmiller points out, the issue with making mass changes to the permissions on a set of files is that there is no guarantee that you will set things back the way they were previously, and regardless of whether it looks like it it's OK, you would be making a huge assumption.

To illustrate, let's use 2 files with the following permissions, which we will then change en masse. The results would probably be something along the lines of:

Before:

-rwxr-xr-x somefile1
-rw-r--r-- somefile 2

During: (chmod as root, per the original post)

-rwxr-xr-x somefile1
-rwxr-xr-x somefile2

Proposed fix (chmod ugo-x, per the recommendation)

-rw-r--r-- somefile1
-rw-r--r-- somefile2

That would restore "somefile2" to the correct level but would break "somefile1", which I would consider to be just as bad if not worse than the original problem. Hence, the safest thing to do IMO would be to reinstall. Granted, a reinstall is a pretty severe solution, however, I would be comfortable in stating that it would be a sure-fire way to restore the proper set of permissions.

Finally, I'll reiterate the point that this situation is an excellent lesson in why running as root is a poor idea. -- J.W.

Makes absolute sense. I gather there is no way to revert to the permissions before the change.

Yes, I realize that I was a fool. Well live and learn. It gives me a good idea for a prog though.... Run in and it will store all permissions. Run in a different mode and restore permissions. Then there are always those files that get added inbetween.

Building a utility like that would be a useful exercise, however, I would caution that changing permissions is not really an action that should be taken on a frequent basis, and similarly, if it is needed, it typically is done on a single file rather than a group. My main point is just to be careful when performing these sorts of system level actions. Good luck with it in any event -- J.W.

I do have a question -

The OP stated in his first post that he accidently made all the files in /bin executable. Seeing as they are executable normally, I would like to pose my original question - What's the problem?

Clearly he may have meant something other that what he said. But he may also have been mistakenly under the impression that he caused a change to his system when in actuality he did nothing at all.

I would agree that changing file permissions on an entire directory is usually a difficult thing to undo correctly - and clearly something to avoid if possible. A glance at my /bin directory, however, showed 2 file types: executables with 755 permissions and symlinks with 777 permissions.

Given a worse case scenario where the OP had made the entire contents of /bin NON executable, the suggestion of chmod -R 755 bin would have corrected the entire problem. Of course, the symlinks would then be 755 and not 777, but they would still be executable by all - just read-only. A little time changing these symlink permisions would have returned the system to normal.

While this particular poster did not mind having to reinstall, I think that an attempt at repair before doing this was at least worth trying. Perhaps getting the output of ls -l on /bin would have been a better start.

Just some thoughts.