5

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.

4 Answers 4

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.

5
  • Thanks, very useful info. ls -U listed sbin etc before proc.
    – Christian
    Apr 10, 2012 at 11:30
  • @ChristianSciberras Only these two? Then it won't probably be very hard...
    – glglgl
    Apr 10, 2012 at 11:34
  • @glglgl: I play Starcraft II and your username was a perfect ending to that comment.
    – gparent
    Apr 10, 2012 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, 2012 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? Sep 1, 2022 at 14:15
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.

7
  • That's all there is to it?
    – Christian
    Apr 10, 2012 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. Apr 10, 2012 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, 2012 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. Apr 10, 2012 at 11:10
  • It wasn't really a major change. :)
    – Christian
    Apr 10, 2012 at 11:12
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.

3
  • 3
    I always cringe at questions like these because they're almost certainly asked by people who don't have backups. Apr 10, 2012 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, 2012 at 14:57
  • @JeffFerland By the way, I specifically mentioned in my question that I did have a backup...
    – Christian
    Apr 10, 2012 at 15:06
1

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .