if the ownership of all files from "root" is changed accidentally on a unix system, what should be the next step?

is there any utility so that the permissions become normal?

Thanks in advance

Hi there.

1) Do not shutdown the system!! Stay logged on as root!
2) do a backup of the user data (check whether the backup is ok), print out information concerning disk arrays/file systems/db-spaces/printers in case you have to reinstall the OS
3) Ask for someone with a similar system and get a list of the ownerships/permissions to change them back

Did the "sticky" bits (execution permission "s") remain? If so, you should be able to reverse the process

good luck

Norbert

thanks norbert.

could u suggest a utility/command for printing information concerning disk arrays/file systems/db-spaces/printers?

how to check for the sticky bits

thanks

Hi,

Remember you can use the binperm6.1 utility to re-correct permissions of the binaries in the $BSE/bin directory if needed.

Originally posted by forsms
if the ownership of all files from "root" is changed accidentally on a unix system, what should be the next step?

is there any utility so that the permissions become normal?

Thanks in advance

forsms, which operating system are you usig exactly?

If all the files owned by root are changed but not the others, that means that the userID 0 was changed to another user?!

If so, you should be able to correct it by reassigning the userID 0 back to root, but how easy it will be depends on your OS (HP-UX thru sam starts a background process to re-assign the userID).

If not, (wrong chown command or similar) then it will be much harder to track which files were affected and you need to compare ownerships with a similar system...

Hi forsms,

as Gerhard pointed out, we need to know which unix you are working with.
As to your question, the tools have differnt names on different systems
AIX: smit (or was it smitty?)
HP: sam
SINIX: sysadm

thats about the ones I know

Disks: /etc/mnttab +
ls -lrtd * >> file for all directories

DB: onmonitor if it is Informix, enterprise manager for oracle(?)

But if you changed the ownership by "chown", you will have to look for someone with a similar system, I really don't believe that there will be a tool - you will have to write a shell script (but this shouldn't be too hard)

As to the sticky bits:
the forth parameter of the file-permissions ("-rwsr-x---" for example) is set to "s".

(On my system, the file "/bin/ct" has the sticky bit set)
This indicates that the user who executes this program, inherits the permissions of the owner of that file. I wonder if these have "survived" the change of ownership.

Again - good luck

Norbert

We are on HPUX11.00.

Actually, the moment I realized that I have given chown at the wrong place, I press "Ctrl-C" many times, and the command exited in between. So I believe that not much harm is done (percentage-wise). But many files now have changed owner's/groups.
Luckily, i was logged in as root, so, could change the owner for 1/2 files (when i was trying to log-in as root from another simpterm session, I was getting a message that ..not proper permissions for such-and-such file... i am not able to recollect the exact filename!!). so i changed the owner/group and now i am able to log in as root.

also, "sam" is working fine.

i am using swverify command as "swverify \*" to get a log of among other things has a log of something like below:
ERROR: File "/opt/dce/bin/camigrate" should have owner,uid "bin,2" but the actual owner,uid is "prod,136".
ERROR: File "/opt/dce/bin/camigrate" should have group,gid "bin,2"
but the actual group,gid is "bsp,125".
...
based on this log, I am changing the owners/groups as per recommended by the log file "swagentd.log"
These sw command and log file is in /var/adm/sw directory.

This swverify is really comming handy (although its a pain to go through the entire list!!!)

Any more suggestions ...

Thanks,