Right, I tried this (on a VM :-)) and got the same behavior you describe. I changed the permissions on
/etc, and rebooted and since I had configured my system to log me in automatically, it attempted to log me in directly and failed.
I don't know enough about Unity's internals to be understand the details but my guess is that when you attempted to login, since the system didn't have access to
/etc it couldn't read all sorts of essential files such as
/etc/group or anything to let it map your username to the appropriate UID and GID. Therefore, upon the attempted login, file details were somehow screwed up.
My guess, and I stress that I'm guessing, is that changes were made to your
gconf configuration settings which then screwed with Unity.
I fixed this on my VM by simply deleting all files from my
$HOME, removing my user and recreating him. Obviously this is not a solution on the system that you actually use.
The only workaround I can think of is to move/rename all the configuration files and directories:
for file in .*; do mv "$file" old_dotfiles; done
This will move all of your configuration files and directories to
~/old_dotfiles. You can then log out and log in again or reboot and things should be back to normal though you will have lost your config settings. You can then try copying them back again. If this is just a file ownership issue, copying them back should reset the ownership and might fix your problem. If the change was made within one of the conf file, this will break your system all over again so proceed with caution.
Bear in mind that most configuration files will be created automatically so you only need to worry about cases where you have made changes to the defaults. Also, you should make sure that "system" folders of your GUI such as
~/Desktop are correctly set up.
My guess is that this should be enough to return you to a working system, with a newfound love for virtual machines.