Accidentally chmod'd everything 777

[jamori]

I seem to have accidentally chmod'd my entire system a+rwx

I issued the following command:

Code: Select all

sudo chmod a+rwx /my/dir -R *

which I know isn't the right order, but I'd already typed a long pathname and didn't want to arrow back and add flags to the beginning. I figured that the program would either a) figure out what I meant or b) tell me it couldn't and bail.

Instead, the permissions on every file on my system are bork'd. Any recommendations on how to get the standard files back to how they should be other than going through manually? I'll obviously have to redo any special files/folders I made, but how about all the standard system stuff?
I'd like to preserve all my config files. Would a forced re-emerge world do it?

Any suggestions would be greatly appreciated.

[timeBandit]

I figured that the program would either a) figure out what I meant or b) tell me it couldn't and bail.
... Any recommendations on how to get the standard files back to how they should be ... ? Would a forced re-emerge world do it?

I bet you won't make that assumption again.
Almost. I think your best bet is:

Code: Select all

emerge -e system
emerge -e world

plus manual fixes to your own files. After the re-merge, you can do this to locate stragglers and decide whether they require correction:

Code: Select all

find / -perm -0777 -a ! -type l -ls

The ! -type l (that's ell,) predicate excludes symbolic links, which always have mode 777. As a point of reference, on my machine that command finds exactly 23 files.

If you haven't already upgraded to GCC 3.4, now might be a good time--a full re-merge is part of the job.

[jamori]

I bet you won't make that assumption again.

definitely not.

Thanks for the advice; it was greatly appreciated.

For some reason, all my services work except ssh (I get connection refused), so I'm going to have to drag it out of a closet to fix this. *sigh*

Thanks again.

[timeBandit]

For some reason, all my services work except ssh (I get connection refused), so I'm going to have to drag it out of a closet to fix this. *sigh*

Thanks again.

You're welcome. As for SSH, it's fussy about permissions on certain critical directories/files (security risk), and will deny connections if they are incorrect. In particular, IIRC the host private keys and sshd_config need to be owned by root, readable only by root (0600), and the directory /var/empty must exist (with permissions 0755). There are probably more such constraints--I'm sorry, it's been a while since I set up SSH, so I can't say which may be at fault. It is mentioned in the config file comments and/or man pages, though, so with some reading you should be able to puzzle it out. Check the logs, too.

Good luck.

[pjp]

Moved from Other Things Gentoo

[wjholden]

I remember having problems after a "chmod 777 -R /some/directory" with a lot of stuff in it, which happened to be content on an FTP server (or something). Because I knew there were some perl scripts in teh folder that I didn't want to be executed, it shouldn't have been possible for any user to execute them anyways, but you can't be too careful, and I fell in love with the "find" command like this:

Code: Select all

chmod -R a-x /some/directory
find /some/directory -type d -exec chmod a+x {} \;

Directories need to be executable (otherwise you can't "cd" into them).

Plus...this might not be a problem with you guys, but I find "a.out" files everywhere

[humbletech99]

This is a beginners experimental mistake, but some people actually like this sort of thing cos it makes everything more open and therefore easier, you don't get lots of access denied... etc, it's why people also run as root all the time. I'd say chalk it up to experience and do a fresh install, I get the impression you haven't been into Linux for too long so there probably isn't much to lose and it might be quicker than try to fix it. If you do want to try to fix it, the chmoding -R 755 / and then adjusting the rest like home dir and the occasional suid or special case may be the only way to go, but it's the long way round. You could try doing a deep emerge world and rebuild everything and see if that replaces everything with their correct permissions

Beware the power of linux, unlike Windows, it assumes you're smart enough to know what you're doing, it doesn't have stabilizers.


For your amusement (probably more for our own really), here's a relevent quote from this forum:

Gentree wrote:

I tell you with the new flux of -ex windows users piling onto Linux we'll be the same mess as Winworld within a year.

from the following post http://forums.gentoo.org/viewtopic-p-29 ... ml#2989221

[mephx]

well, accidentaly chmoded 777 ./.* as root, then went away for a smoke, when i was back, jeez, my box looks like a bit&/%!! is there any fast way to re-perm all the fs?

by hand may be out of question :S

thanks

[fangorn]

As gentoo systems are quite different from box to box, I dont think there are some scripts to repermission everything.

The most complete way (and with the minimum of handwork) is to just repermission your /home and /etc and rebuild the system with a stage3, copy the handedited files from /etc/, your /home and world file and "emerge -e world".

[lxg]

Maybe I'm on the wrong path, but wouldn't in this specific situation an emerge -e world suffice?

[mephx]

thanks,

even so... i'm currently on a deadline approach, so no emerge world for 200 and some change packages.

chmoded most of the fs by hand.

there should be an easy way to store/restore perms. portage or not

cheers

[PaulBredbury]

an emerge -e world suffice?

No, because re-emerges don't reset the permissions of existing files. Unless they do so in e.g. pkg_postinst(), outside of the sandbox. Or unless Portage has got a bug.

Edit: Hmm, just experimented with /etc/conf.d/microcode_ctl and portage-2.2_rc22, and portage *did* reset the file's permissions after an emerge. Toss a coin, to determine Portage's behaviour this week

[chris.c.hogan]

accidentaly chmoded 777 ./.* as root

I'm assuming you used chmod -R 777 ./* from root as root. chmod 777 ./.* would only have changed the permissions on hidden files in the current directory. Either way, it would make the files in question user/group/world readable/writable/executionable. It makes for an insecure system. However, with the exception of files that need to be setuid/setgid, your system should function. Of course you'll want to repair the damage.

there should be an easy way to store/restore perms. portage or not

If you are just interested in backing up and restoring permissions, you could do:

Code: Select all

cd /
ls -Rl > backup.perms

You could then write a script that feeds the generated list back into chmod to restore. However, a better method would be to tarball your system to DVD. It provides much more protection. Excluding /home, /tmp, and parts of /var, it should fit on one or two disks.

If you happen to have a reference system, you could also take advantage of chmod's --reference=rfile option to fix things.

[timeBandit]

http://forums.gentoo.org/viewtopic-t-41 ... d+777.html
Forum search, lame though it may be, is still your friend....

[mephx]

If you happen to have a reference system, you could also take advantage of chmod's --reference=rfile option to fix things.

this sounds interesting...
but, how do i generate that rfile? :S

thanks everyone
~x

[kallamej]

Merged [post]3782519[/post] and onwards to this thread.

[mephx]

anyone?

[timeBandit]

Sorry, thought the person who posted that would reply.

The "rfile" mentioned isn't a generated file--I assume you were hoping it was a file listing all the correct permissions to apply. It's not. What chmod --reference=fileA fileB does is set the mode (permissions) of fileB to be the same as that of fileA (the reference file).

[Yura]

i was installing gentoo (openoffice) when free disk space ended... I decided move /usr directory to other partition (it was at root) i execute cp -r /usr /mnt/r/

(/mnt/r - ext3 partition) in /etc/fstab i wrote:
/mnt/r/usr auto bind 0 0

old /usr i deleted.

boot gone successfully.

but when i logined as user and typed startx it wasn't execute;
i looked at /usr/sbin and saw that no files had SUID bit.

for some files i set it manually. but it's to hard to set it for all files. reinstall all in /usr because 1 bit is very long and pity.

1. Have somebody any ideas ?
2. and why suid bit was lose when copies with cp ?

[eccerr0r]

For #2 - You'll need to cp with -p to copy/retain permissions and owners.
As for #1, I'm not sure if there's a record of suid bits anywhere... this might be a good feature to add to portage? Not sure...

[timeBandit]

Merged above two posts here since it amounts to the same problem. Unfortunately, as pointed out above it's necessary to re-merge everything to be sure it's all fixed.

[eccerr0r]

I think portage, after every file is cataloged (it does MD5 everything?), also record group/owner and file modes. I don't think these really are quite as helpful as the md5, but can help in situations like these as it appears people screw this up more often than one would think.