Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

i just ran this a few seconds ago, i managed to do ctrl-c as soon as i realized what i started doing.

so far in the only dir its started going through is /bin

im afraid to do anything else, so far i realize i can't use "su" as my normal user anymore.

luckily i still have another root terminal open, what to do?

share|improve this question
24  
Sounds like you got chowned there, buddy. –  ta.speot.is Jan 25 '10 at 10:57
3  
Now you understand the importance of backups. Do it regularly. –  Juliano Jan 25 '10 at 12:45
    
At least he didn't chmod from root. That's a full-on disaster. At least rm -rf from root gives you more disk space and prepares you for a full system reinstall, chmod just leaves a real mess that's pretty hard to recover from by anything besides a complete system reinstall. The grass is brown on both sides of the fence, eh? –  Fiasco Labs Dec 10 '11 at 19:24
add comment

8 Answers

up vote 10 down vote accepted

Most everything in /bin/ should be owned by root:root, so if you run the following you can fix the ownership on those files:

chown root:root -R /bin/ 

You may also want to make sure the setuid bit is properly set on /bin/su, which you can fix with the following:

chmod 4755 /bin/su
share|improve this answer
1  
On Ubuntu, it's especially important to do the same with sudo. I don't think that a root password is even set by default? By the way, I'd really recommend actually using sudo instead of root shells. The half-second it takes to type sudo normally stops mistakes like that in the tracks. Just working in a root shell is easier to miss... –  Bernd Haug Jan 25 '10 at 7:35
4  
paste.ubuntu.com/362468 is a "ls -l /bin" from my Ubuntu 9.10 desktop. While I might not have exactly the same files installed as you, it should at least give you a good hint on which files need special permissions. –  andol Jan 25 '10 at 9:03
    
@Bernd: Although I don't do that much admin work, I have noticed that I sudo fewer dumb things than I do as root. I may never use a root password ever again. (And, no, there is no default root password on Ubuntu, and I don't think there is one on MacOSX.) –  David Thornley Jan 25 '10 at 14:49
    
@David: There definitely is no default root password on OS X, and setting one is mostly a mistake, IMO. There's almost always another, better way. The problem is that Macs are not too secure to begin with; I expect to see a lot of 'fun' once they have a larger install base to make RKs, Virii, Botnet clients &c profitable. –  Bernd Haug Jan 25 '10 at 15:44
add comment

Redhat user:

chown 0:0 /bin/rpm && rpm -qa | xargs rpm --setugids

Debian/Ubuntu user:

chown 0:0 /bin/*  /usr/bin/*
chown daemon:daemon /usr/bin/at
chown 0:utmp /usr/bin/screen
chmod 02755 /usr/bin/screen
chmod u+s /bin/fusermount /bin/mount /bin/su /bin/mount
chmod u+s /usr/bin/sudo /usr/bin/passwd
screen

While screen is running do this at least twice:

dpkg --get-selections | awk '{ if ($2 == "install") print $1}' \
    | xargs apt-get install --reinstall --

Pay very close attention to the output because if it complains about something having the wrong permissions, you should fix it on another screen window.

Crash course in screen:

Control+A     - command key
Control+A a   - emit a control+A
Control+A n   - next "screen"
Control+A c   - create "screen"

Solaris user:

You're fucked.

pkgchk -R / -f -a

will reset all the permissions, but setuid-ness will still be broken. Use a backup, or another solaris machine to look for setuid/setgid scripts and files and fix them up manually.

THE IMPORTANT THING ABOUT BACKUPS

Is that you can recover them, not that you take them.

Other people have given you advice to take backups, but I want to add that you should be testing them. If you're using a unixish system, there is no reason whatsoever that you can't dump the files onto another machine periodically and make sure everything works.

share|improve this answer
    
FreeBSD User: would never make this kind of mistake ;) –  einstiien Jan 25 '10 at 17:28
7  
@einstiien Yep, FreeBSD users go straight to the rm -rf stage. –  grawity Jan 25 '10 at 18:15
    
@grawity: lol, good one. –  einstiien Jan 25 '10 at 18:22
    
Poor Solaris users :( –  Mircea Chirea Jul 7 '10 at 13:14
add comment

Be aware that the set-uid flags on any affected binaries may have been removed, too; this is a security feature of chown. Check with some other system which binaries have the set-uid or set-gid flags and be sure to set them on your binaries as well.

share|improve this answer
add comment

I was going to explain the details of using RPM to reset file permissions, but I've found a site with a lot more information. It does also mention that Ubuntu/Debian (so .debs in general) don't support it.

But in general the option your looking for would be along the lines:

rpm --setugids {packagename}
share|improve this answer
    
This is on an ubuntu system, as indicated by the tags. This means that dpkg and .DEBs are used instead of rpm and .RPMs –  Kevin M Jan 25 '10 at 15:44
add comment

If this was a debian system, I'd aptitude reinstall everything.

share|improve this answer
add comment

do you have a working backup? when yes, restore your bin folder.

otherwise, look at an other box where you installed the same version of ubuntu and chown to what you find on the working installation.

share|improve this answer
add comment

try this: find all www-data in /bin directory

# find /bin -user www-data

then change www-data back to the original user

# find /bin -user www-data -exec chown ORiginalUser {} \;

# then change www-data back to oringal group
# find /bin -group www-data -exec chgrp originaluser {} \;
share|improve this answer
add comment

Thanks all for the great responses, everything seems to be fixed now.

/bin/su worked once chmod'd to 4755 (not sure why chown changed the suid bit)

i didnt notice but it also started working through the /home directory but that was an easy enough fix (just set user:group to the user for each dir)

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.