Recovering from bad chown command

Question

I was going to change the ownership of a directory to apache:apache, but I ended up running:

chown -R apache:apache /

Bad! Very bad! I knew what was going on when it started saying:

chown: changing ownership of `/proc/2694/fd/48': Permission denied

That's when I stopped everything (Ctrl+C).

The current system I have is a server running virtualbox running CentOS 5. This problem happened inside the VM.

Currently, everything seems to be working, but I have not restarted the system yet, and to be honest, I'm afraid that if I did something will break.

I do not know chown's order, should I be concerned and assume something will break after a reboot? Is there a way to recover form this problem without having to rely on backups? I do have a daily one, but I thought there may be a simpler way out.

score 9 · Answer 1 · answered Apr 10 '12 at 11:03

9

rpm --setugids will restore ownership for the packages passed to it. Pass -a to restore all packages. You may also need --setperms to restore setuid/setgid permissions.

answered Apr 10 '12 at 11:03

Ignacio Vazquez-Abrams

45,019
5
78
84

That's all there is to it? – Christian Apr 10 '12 at 11:07
1

Well, it can't help you with files that aren't in the rpmdb. Those you'll need to handle yourself. – Ignacio Vazquez-Abrams Apr 10 '12 at 11:08
But how do I know which ones to change? What if the machine won't reboot (what are my options then)? – Christian Apr 10 '12 at 11:09
"Restore from backup" and "Make note to create a snapshot before making major changes to a VM" are notes I've learned to memorize. – Bart Silverstrim Apr 10 '12 at 11:10
It wasn't really a major change. :) – Christian Apr 10 '12 at 11:12
It turned into one :-) When doing the proposed fixes, you might want to snapshot the VM first. – Bart Silverstrim Apr 10 '12 at 12:59
@Bart I did. I also took two snapshots *after* restoring. Just in case. :) – Christian Apr 10 '12 at 15:05

score 7 · Accepted Answer · answered Apr 10 '12 at 11:26

7

It would be good to have an old backup, but IMHO it would suffice to be able to extract the ownership data.

I would it do this way:

First, make a backup of the current state.
Then, restore the original properties according to the RPMDB. This will probably repair a lot of your files
To identify and repair the remaining ones, find all files which are still subject to this problem. These are the files which belong to apache:apache and are in the "search order" before /proc . Maybe you do
```
ls -U /
```
first and get the list of root level entries before /proc (I suppose this is where you canceled the process).

Then do a
```
find /foo /bar /baz -user apache -group apache
```
replacing foo, bar, baz with the entries identified before. Redirect find's output to a file.
Extract all the ownership data of the given files from the backup and apply them to the files.

answered Apr 10 '12 at 11:26

glglgl

712
1
6
22

Thanks, very useful info. `ls -U` listed `sbin etc` before `proc`. – Christian Apr 10 '12 at 11:30
@ChristianSciberras Only these two? Then it won't probably be very hard... – glglgl Apr 10 '12 at 11:34
@glglgl: I play Starcraft II and your username was a perfect ending to that comment. – gparent Apr 10 '12 at 13:59
After a while, I realized `/bin` was also modified. It works perfectly now. I'm marking this as the answer since it's much more detailed and practical. Thanks. – Christian Apr 10 '12 at 14:58
@Christian i know we have come a long way since this has been posted ... but can you please help me out ... i have taken a snapshot ...what am I supposed to do now? – Cherryl Rarewings Sep 01 '22 at 14:15

score 1 · Answer 3 · answered Apr 10 '12 at 11:11

1

In all honesty it's easiest to schedule a proper restore from your last backup at this point. Fortunately you can still do another, final, backup to preserve your current user data; then restore your old backup, and finally restore your user/customer data from your final backup, making sure you preserve the permissions of each group of files as you do so.

answered Apr 10 '12 at 11:11

Sam Morris

345
1
10

3

I always cringe at questions like these because they're almost certainly asked by people who don't have backups. – Jeff Ferland Apr 10 '12 at 13:45
1

I do have a backup, but I'd rather not loose employees work of the last 2 days. – Christian Apr 10 '12 at 14:57
@JeffFerland By the way, I specifically mentioned in my question that I did have a backup... – Christian Apr 10 '12 at 15:06

score 1 · Answer 4 · answered Apr 10 '12 at 15:17

Since you're one of the ~~lucky~~ smart enough folks to have implemented a daily backup, here's what I suggest:

If you can access your backup catalog directly, you can use that to scrape permissions off all the files. Bacula, for example, stores the metadata in a database and file data can be viewed using SQL queries.

It is also possible to restore all your files to a separate location and read the filesystem from there to determine the appropriate permissions.

For each file on the system you have clobbered with chown (find / -user apache -group apache), check for the corresponding file on your backup. If it exists, restore the user and group. If it doesn't exist, flag it for later review and move on.

This process will keep all your data current and prevent clobbering a day or two worth of work. The RPM database permissions restore is a good idea, but where you have backups you can accomplish a greater degree of the work in one pass.

Recovering from bad chown command

4 Answers4

Linked

Related