There are a few directories/files created in /tmp for X (when you start X there will be a X0 socket as well as others in there). The sound system will also use /tmp. Now some of these programs that write to /tmp are not running under your userid, they are running under other IDs such as root. When these processes create files the files are owned by that ID and generally you don't want one ID to be able to delete things created by another ID, that would be a huge security violation, hence required you to be root to remove them.
Can you imagine on a multi-user setup when you have more than one user logged in what would happen if one user were allowed to manipulate another user's files? Not good. Now, I wish you would have asked this question before reinstalling because it would have only been about a 10 second fix to get you going again. The system wouldn't be very secure or stable if a normal user had the power to screw up the system or other user's work.
Now knowing the root password essentially makes you the "system administrator". Historically only people who really know what they are doing have this power but on a desktop system it obviously isn't as critical and is a good way for a person to *become* that expert as in your example.
Generally /tmp *is* a shared area that everyone has the ability to write to and most apps use this area for creating temporary files (or /usr/tmp or /var/tmp, there actually is a philosophy for using one over the other but it isn't that important at your stage). Just remember that Linux is highly concerned about security.
Each logon ID normally would have full power over it's home directory and full power over anything that ID creates. But that logon ID should not by default have access to remove anything created/owned by any other logon ID, and have varying degrees of access below that (on a need to know basis).
[ September 06, 2002: Message edited by: void main ]
