Re: System broken with chown -R as root

From: Moe Trin (ibuprofin_at_painkiller.example.com)
Date: 07/19/04


Date: Mon, 19 Jul 2004 08:57:10 -0500

In article <2lv4cfFgbpdiU3@uni-berlin.de>, nospam55 wrote:
>Thank you all for all answers.

More below.

On Thu, 15 Jul 2004 11:51:14 +0200, you cross-posted to a number of newsgroups

>some weeks ago I said inadvertently ' chown -R /* user1:user1 ' as root ; the
>seemingly affected dirs were /bin /boot /dev /etc ;

Whoppie!! Well, it could have been worse I suppose. ;-)

>terrified I made a full backup,

but where was the previous backup?

>then tried to repair with
>
> chown -R 0:0 /bin /boot /dev /etc

As others have pointed out - this is not quite correct, because there are
files (and directories) that have to have other ownerships. Also, AND THIS
IS A BIG POINT, when you chown a file to root, it looses any special
permissions, like SUID or SGID. There are some critical files that depend
on being SUID root.

>and restarted. the system and its dialup connection seemed working.

That _suggests_ you are logging in as root instead of as a user. Don't do that.

>But yesterday I noticed that my HP670C printer doesnt work

Yeah, user 'lpd' should own some devices, and some of the printing
applications may run as group or user 'lpd'. When you chowned the files,
this was lost.

>I m afraid I must reinstall the system because of this printing problem,
>but it would be philosophically more satisfactory to fix the problem with
>chown and chmod

As others have pointed out, rpm can do a lot of this for you. But at least
in the articles of this thread that I have seen, nobody mentioned trying
the verification mode - "rpm -Va" as root.

>Or a way to reinstall only the print subsystem?

Restore from valid backups ;-)

Now, back to the current post:

>Unfortunately I'm still unable to print,
>Reinstalling the whole system is the only idea
>I still have, a M$oft-like situation ... :-(

At this point, it's probably going to be quicker. You should:

1. Back up any stuff you need to keep (/home/* for example).

2. Reinstall from scratch.

3. Hit the errata site, and install all applicable updates.

4. Create a new backup tape - current system.

5. As root, run the command 'rpm -Va > strange.files' to create a
file that shows the differences between what rpm expects, and what is
actually on your system now. Note that rpm only knows about files and
directories it installed/created, and some files (often configuration
files) will be different.

6. Restore the stuff from step 1 above.

7. Create a new backup tape - current WORKING system

8. Repeat step 5, and stash that "strange.files" file away for
safe keeping.

9. Design AND IMPLIMENT a regular tape backup schedule. How much you
back up and when is up to you - and you know how much easier it would
have been if you had working backups.

Regarding step 5 above, I run that command weekly, looking for changes.
There is also a program called tripwire (called "a system integrity
assessment tool") that has been part of Red Hat since RH 6.2. If you
want to use that, you must use it initially on a working system to create
the "this is normal" snapshot that you will later compare against.

          Old guy



Relevant Pages

  • Re: PAM problems
    ... were committed as the root user, but since you have root access I'd ... suggest that you backup all his important data, re-install the OS ... remove that last rpm installation and see if the problem persists. ...
    (linux.redhat)
  • Re: Setting permissions of ssh access
    ... my main goal is to use rsync-backup once I have a good test case going. ... It struck me as odd as well, and I am going to go back to pushing the data from the machines out to the single backup machine, which I can section off to not even be accessible to the outside world. ... As I go through this process, I will document it, as there were some pretty strange thins happening with sshd_conf and not letting me have a root login. ... static command on the backup server's side, ...
    (SSH)
  • [Summary] ufsdump, solaris 9 & RBAC not working correctly
    ... server, and I don't want to have root logging in on the remote server, I ... etc. and key exchange setup for backup user. ... ufsdump, solaris 9 & RBAC not working correctly ... I thought suid was suid. ...
    (SunManagers)
  • Re: Backup advise
    ... as I wrote a backup script to backup specific files to an external drive ... rsyncheap statistics: ... Literal data: 8590417920 bytes ... The end results of the RPM building process failing is to leave the ...
    (alt.os.linux.suse)
  • Re: Can "/etc/rc.conf" be replaced with a symlink?
    ... > I changed fstab so that my data partition would supposely mount ... > before root, moved/symlink'd rc.conf, and rebooted. ... and you can only work from root to recover (which doesn't get hosed as ... though you can do a standard install and untar a backup ...
    (freebsd-questions)