Reconnaissance
Sadly, at least one UNIX plops all new users into the same "users" group. When you get on one of these machines, a lot of information in all home directories is revealed. Anyone who is a "user" can examine scripts that other users create, looking for weaknesses. How is this possible?
The default permission for home directories is 755 on many systems. With these permissions, you give anyone with a login account (or an intruder) open access to read most files and to traverse all directories internal to the home directory. Remember, more and more production work is run out of home directories. And most home directories give anyone with any kind of access to the machine an invitation to explore all files in all directories. This arrangement lets people snoop for security weaknesses.
But something worse happens in a UNIX that plops all users into a common group. Many people are opening group-access rights. They want to give other workgroup members open access to shared files. Unintended users may get access rights as well, and we're implying the important write access, as well as just the ability to check all scripts for weakness.
So, with a traditional UNIX that gives 755 home directory permissions, all home directories are open to exploration. In fact, the group permissions that allow workgroups may enable a lot of extra writers in your home directory. Let's examine one last example of writing and reconnaissance fostered by this default arrangement, and then we'll consider the risk that administrators face.
A very special risk comes about when hurried/harassed administrators are pressured into setting a generous FTP UMASK. Most web-content managers demand an FTP UMASK that supports group access as each file is placed on the server. For those who aren't familiar with the concept, the UMASK is a file permissions "mask" or set of bits that dictate the default permissions for each file as it's created or written to disk.
Many Windows users are unfamiliar with UNIX file permissions. They use FTP to transfer web content, for example, to the web servers. Despite having nice GUI tools to automate FTP and despite most FTP clients' support for the chmod command, these users place files on the server and never change the file permissions from 755 permissions to 775, or whatever else is appropriate. When their teammate can't edit the HTML file, users complain, loudly, about your problem.
Many administrators read man ftpd and find that there's a way to adjust the UMASK with many ftpd versions. This allows you to set the default UMASK so that every file is now put on the server with 775 permissions; in other words, group write enabled. Problem solved. Except that now all files loaded to the serverincluding those loaded to the home directorieshave 775 permissions.
Are you an administrator in the Users group? Is Users your primary group? Administrative scripts, located in administrator home directories, are writeable to whatever group owns the file. Yes, some administrators will su to root and then run scripts owned by their base ID and their base groupin many cases, that's Users.
Administrators with root access may find that their own home directory settings will betray a way to get root. Intruders will alter their "private" scripts and add little commands.