Permissions Coloring

When you choose Permissions Coloring in the contextual menu, the icons are colored according to who owns it, and what permissions are granted. The color key shows how.

  X11 MacOS
Age/Permissions coloring toggle altG ^G
open color key altI ^I

color key

Your files are colored with purple colors. The different hues reflect how restrictive the permissions are that you have assigned for other people. The more red the color is, the more restricted you have made them.

Files that don't belong to you are colored either orange or khaki green. As with your own colors, the closer to red, the more restrictive, except here, you only are told whether you have or don't have access. It's not your file, after all.

For directories, the permissions depicted are actually the most permissive found in the directory and all of its subdirectories - not just the directory's permissions itself. This way, you can see if ANYTHING is writable or accessible inside, no matter how deep.

During tallying of a large directory, there is a tendency for the directory colors to get less red as time goes on, because as the tallying proceeds deeper, there are more opportunities for more permissive files or directories to be discovered.

The most obvious color is the inside color for the icon, which shows you the write permission.

The outside of the icon has its own color. This is the access (read) permission. Very commonly, you will see the outside color is more permissive than the inside; that is, read permission is granted more freely than write permission.

The file name itself has yet a third color - the Execute permission. For a regular file, this marks the file as a runnable program, such as a script or a binary program. Typically, regular data files will have NO executable access, even for the owner. In other words, the file name wine-red. Executable files also have an X icon rather than a paper page icon.

Unfortunately, files from non-Unix operating systems often get this bit set, simply because there's no executable bit on the original data, and it's safer to leave it on than to leave it off, rendering a formerly runnable program nonoperational. On MacOS, of course, the non-Unix environment is intermingling with the Unix environment, so this is fairly common.

For a directory, executable permission simply allows you to use the directory name in a path to another file. Execute permission on a directory is sometimes called search permission because the OS will search, on your behalf, for a filename that you spell correctly. Ironically, you yourself cannot search for a filename with only 'search' permission; in order for you (that is, a program you run) to get all of the filenames in a directory so you can rummage through, you need Read permission (the outside of the icon). U

Therefore, unless you can spell the filename correctly, the OS will not help you out if you only have Execute permission in the directory. In such a directory, you can type in a name of a file that you think exists in an Interrogator directory window. A message tells you this if the situation is right. If you manage to spell it correctly, you can then use the file as in any other situation. If it is a directory, you have normal access to any files or subdirectories inside.



This directory is a personal home directory. Notice how all the files belong to 'me', except for the file .., which is the /Users directory, a system directory owned by the superuser.


This directory is the /etc directory on MacOS X. All of the files and directories are unwritable, and some are even unreadable. This is for good reason. Etc is sortof the unix equivalent of a system-level preferences directory; it contains all sorts of files that specify options that control parts of the OS. For instance, the httpd directory contains configuration information for httpd, the web server daemon, that is, Apache.


This directory is the Applications directory on MacOS X. Applications that were deposited at OS install time are owned by the superuser and appear green - they are totally writable. Applications installed later, by me, appear in purples and blues. The purple ones were copied there, and the permissions exclude anybody but me. Well, it's my laptop, I don't care about anybody else. But, Adobe Photoshop was deposited by an installer that made sure to set its permissions to allow anybody in.


This directory is an attachments directory for an email program. Many of them are spam pictures or email worm programs intended for an MS Windows victim. Every single file belongs to me, and excludes everybody else. Most of them have the executable bit set, too, suggesting that they were received while Mac OS 9 was running.


This directory is the /dev directory in Mac OS X. As with most other kinds of Unix, it is filled with special device files. You can't even open this directory in the Mac finder, it doesn't let you. Almost all of the files are owned by the system; the exception is the console device, which is inexplicably owned by me. The rounded-corner trapezoids are serial device files; they act like a stream of bytes. Most of them are pseudo-terminals (pty) which are needed for the Terminal application, and any other situation where some program needs to be faked out with a device that appears to be an old-fashioned ascii terminal. The system cannot create them on the fly; what you see is all of them, and they are handed out carefully by the system. As you can see, most of them are wide open for use by anybody.

The rectangle icons that look like parallel plugs are block-special device files; they represent disks, or disk partitions. As you would expect, these are tightly controlled by the system, otherwise anybody could scan through files that don't belong to them, or even modify them.



This is the root directory for my laptop, named Valencia. It contains a mix of files that belong to the system and files that belong to the owner. MacOS X is like that. Linux and Solaris systems are more tightly controlled at the root; everything at the top is typically owned by the superuser in those cases.


This directory is /usr on MacOS X. /usr on any Unix system typically contains software - lots of it. Newly installed Unix systems might have up to 80% of their bytes stored under the /usr directory. Of course, MacOS X has a lot more outside of /usr, like most of the Macintosh part.

Executable programs are in /usr/bin, and libraries in /usr/lib, for instance. /usr/local is empty - you can tell by the torn icon. On other Unix systems, /usr/local might have a lot of things in it. All of /usr should be unwritable, to guard against tampering. But for some reason, the share directory seems to have something writable in it. Let's investigate this by opening up /usr/share.


This directory is /usr/share, parts of Unix that are shared, so to speak. This has sortof lost its meaning over the years; originally it was software shared between users, which describes almost all of modern Linux systems. We can see that everything is write-protected, as it should, except the man directory, which has documentation in the man format (for the command line man command). Let's open that up and see what is the problem.


This directory is /usr/share/man. Each directory refers to a chapter in the "Unix Programmer's Manual", a manual that doesn't really exist in paper form anymore, although the man command prints out pages with headers, footers and page numbers. man1 describes commands you might find in /usr/bin, and man3 describes library functions you might call from a C program. We can see that everything is as it should be except for the cat1 directory, which seems to have something writable in it. Let's open that up.


Finally we get to the source of the problem - the file open.1 - and we can find out all the details by getting a Full Disclosure on it.
Type this to see the Full Disclosure report.
  X11 MacOS
Full Disclosure on the open.1 file o p e n . 1 altF altI o p e n . 1 ^F ^I

We can see that this file erroneously is set to be world-writable! Someone at Apple Corporation must have made a bit of a mistake to let it out this way. Theoretically, some malicious user, like me, could go and change it. If this was a multi-user system and not a laptop, this might be more serious.

Red Permissions

Red indicates some sort of error. It could be that Interrogator gets an error every time it tries to get information about the file, or that the file header itself is corrupt. Or, it could just be a crazy permission setting. (You can quickly tell if it's just a permission problem by switching between Age and Permission coloring.)

If the file is yours, the red color could be because of a nonsensical or insecure permission setting. This is almost always due to a permission inversion - where the world has more permissions than the group or owner, or the group has more permissions than the owner. Almost always, the more specific group of people should have permissions that are the same or better than less specific groups.

For instance, a file with a mode of ---rwxrwx allows everybody to do everything, except for the one person who's designated the owner, who seemingly can do nothing. Unfortunately, the owner is allowed to change the file's permissions - regardless of the mode bits - and therefore can turn on all the permissions for themselves. (And turn them off for everybody else if desired.) If you were trying to prohibit one specific user from accessing the file, this isn't the way to do it.

A more subtle situation comes when the world has more permissions than the group, say a mode like rwx---rwx. The owner has all permissions. The world has all permissions. But members of the group are specifically shut out. At first glance, this too could be seen as a useful technique to prohibit a specific group from accessing the file, but it's a risky method. Any intruder who figures out how to shake off the group membership can then get in. A common way to do this is to log in using a 'guest' account (assuming the guest account is not a member of the group). If the system is running a web or anonymous ftp server, client activities are usually done under such a userid, sometimes named 'nobody' or 'www'. Combined with other hacking techniques, a regular user could break into this file. For instance, they could write a Perl script to do their dirty work, and then place it where it can be surfed to. Then they surf to their own script and they're in.

Documentation > Directory Window > Permissions Coloring        

                     

T a c t i l e   I n t e r r o g a t o r   W e b s i t e