UNIX/Linux CHOWN - Looking for a solution

C

civic00typer

Gawd
Joined
Dec 5, 2003
Messages
517
I am currently taking a UNIX/Linux course (which assumes prior knowledge that I don't have)... and we were presented with a case study. Apparently a non-technical person had root access to a AIX system and ran the following command: chown -R plead:user *. This command was run accidently on the /usr directory and now the system is no longer functioning (it should have been run on some files in his home directory).

Now the system administrator needs to fix the problem. The only solution I see is booting to single user mode and manually changing all the permissions back. However, this is a tedious process and I am hoping there is a better answer. Can you undo the chown command? If not, would it be feasible to run the .UNCOFNIGURED startup script to reconfigure the system? I apprecaite any help or guidance you can give me to solve this problem.
 
I think you had it correct in the beginning to go into single user mode and change the permissions, now if you could just write your own script to automate that, it wouldn't take any time at all. I would assume that is what your teacher would be looking for.
 
Well I am assuming you can't just set the permissions back to root on everything. I might be wrong here... processes can own files (if they have a user account associated with them), correct? Therefore, determining who the original owner of the files is would not be an easy task.
 
chown root:root on that dir is a good place to start

I don't know AIX, but if it was any of the linux flavours I would get the package manager to re-install any package that installed a file to /usr

does AIX do backups. do a restore of backup
 
package-manager specific (but gonna be virtually all of them in linux)

but for gentoo a case of

for PKG in `eix -I --only-names`; do equery files "${PKG}" | grep /usr ...

but generally that
List all installed packages, then query those packages to list installed files, grep for /usr and emerge what is required
 
This is AIX?

Yeah, you're pretty much fucked.

step 1. Try root:root for everything in there.
step 2. A pinch to get everything ~running~ would be a world-all chmod, and then start locking down again.
step 3. Ban the user from the system for a month. Teach the bastard to do shit like that.
step 4. Time to restore from your most recent tape!

AIX doesn't have a nice package manager like you all think, sadly. SMIT is pretty unreliable when it comes to queries like that. And no, you can't just undo the chown that I know of.
 
lopoetve said:
step 3. Ban the user from the system for a month. Teach the bastard to do shit like that.
Click to expand...

I looked here on my own Linux boxes (AIX is probably similar) and root owns everything in /usr so chown -R root:root /usr is probably a really good place to start.

as to banning the user, the admin should be fired for ever letting a user get root access in the first place.
 
svet-am said:
I looked here on my own Linux boxes (AIX is probably similar) and root owns everything in /usr so chown -R root:root /usr is probably a really good place to start.

as to banning the user, the admin should be fired for ever letting a user get root access in the first place.
Click to expand...

read again - the user didn't HAVE root, he was just a normal user. That means he only whacked things that were world writable. On AIX, sadly, there are enough of those that it makes a mess >_<

I know this because 6 months ago a user had a script taht did a rm -rf /$VAR...

only when $VAR is un-matched, well, then it does rm -rf /

... not as root, but it still took 12 hours to get everythign back.
 
civic00typer said:
Apparently a non-technical person had root access to a AIX system and ran the following command: chown -R plead:user *. This command was run accidently on the /usr directory and now the system is no longer functioning (it should have been run on some files in his home directory).
Click to expand...

No disrespect, lopoetve, but you need to read again. The non-technical person had root access.
 
Step 1: chown -R root:root /usr
Step 2: Put gun to sysadmin's head and pull the trigger.
Step 3: Find a sysadmin who is not a complete fucking moron.

 
svet-am said:
No disrespect, lopoetve, but you need to read again. The non-technical person had root access.
Click to expand...

>_<

This is what happens when you just spent 6 hours reading through someone's SAN logs trying to figure out what the hell they're doing with their cluster and then read [H]
 
Hm, I wonder if you have access to another AIX box.......if you do you could try rsyncing the permissions back. Not sure if there is a switch JUST to copy permissions back.
 
Robstar said:
Hm, I wonder if you have access to another AIX box.......if you do you could try rsyncing the permissions back. Not sure if there is a switch JUST to copy permissions back.
Click to expand...

That's an interesting idea. I skimmed my rsync manual and I didn't see any way to do that, but it wouldn't be difficult to do such a thing manually.

1. use 'find /usr -printf <something>' to get a list of all files and their ownerships
2. copy the list to the damaged machine
3. write a script in your language of choice to set ownership according to the list
4. search for any remaining chowned files and deal with them manually

I'd be wary of doing that on a production machine, but I wouldn't hesitate on a personal system.

-Corey
 
SmokeRngs said:
Step 1: chown -R root:root /usr
Step 2: Put gun to sysadmin's head and pull the trigger.
Step 3: Find a sysadmin who is not a complete fucking moron.

Click to expand...
Thread+ I had a longer response, but this shorter and gets to the point.
 
Ignoring the root issue for a moment, any sysadmin that doesn't have a backup system in place capable of handling this needs to be canned.
 
Arainach said:
Ignoring the root issue for a moment, any sysadmin that doesn't have a backup system in place capable of handling this needs to be canned.
Click to expand...

Thus, one of the reasons for steps 2 and 3 in my answer.

 
You must log in or register to reply here.
Back
Top