|
9/18/2001 -- I liken the Unix filesystem to Marcel Proust's "In Search of Lost Time": Each took about 25 years to coalesce, can take equally long to comprehend, and are chock full of false starts, red herrings and simple dead ends. Without a road map, it's easy to be overwhelmed.
Unix Directories
Below is an imaginary schemata for a Unix filesystem layout -- imaginary because no Unix distribution adheres to this scheme precisely. Even so, it's a good starting base for understanding Unix filesystems. I've also included "rough" Win32 file equivalents for each directory. (These are not all perfect. For instance, while Windows device drivers actually reside in the C:\winnt\system32\drivers directory as DLL files, files in the Unix /dev directory are not device drivers themselves, but merely methods to communicate with the actual drivers, whose location varies.)
| Unix Directory |
Contents |
Close Win32 Equivalent |
| /bin |
Essential system programs, executable binaries |
C:\winnt\system32 |
| /etc |
Configuration information, et cetera |
the registry, C:\winnt\system32\config |
| /dev |
Device files representing the system's hardware. |
C:\winnt\system32\drivers |
| /lib |
System libraries, akin to Windows DLLs |
C:\winnt\system32 |
| /usr |
User home directories, end user software. |
C:\Documents and Settings, C:\Program Files |
| /tmp |
Temporary data |
C:\temp |
| /unix |
The system kernel file |
C:\winnt\system32\ntoskrnl.exe |
| /var |
Variable but permanent data such as system logs |
C:\winnt\system32\config |
Unix directories are named using the same shorthand as Unix commands, and each vendor adds their own eccentricities. Linux adds a /proc filesystem which contains information about currently running processes. Solaris moves /bin to /usr/bin, and also adds an /sbin directory, to distinguish between administrative commands and programs intended for general use. The directory /usr/local is commonly used to store software not bundled with the OS.
Some directories are named functionally: For instance, an /export directory may mean that the filesystem is being shared -- i.e., "exported" -- via NFS, the Unix equivalent of Windows peer-to-peer filesharing.
7 Types of Files
You'll notice I also listed /unix -- the system kernel -- above. The operating system kernel is an executable file, just like the Windows kernel. This file is sometimes moved to a subdirectory, like /kernel/unix on Solaris or /stand/unix on SCO Unix. However, had I not identified /unix as a file, you might not have known it from the above listing. File extensions such as .exe and .txt, which associate Windows files with applications, don't exist on Unix except in situations where they're functional -- for instance, in directories containing Web content such as .html files or where they serve to improve human readability. There are quick, non-invasive commands to use if you have no idea what a particular file might be (as always, the dollar sign represents the shell prompt, akin to the Windows C:\> prompt, and is not meant to be typed as part of the command):
$ file
For instance, here's the information on the kernel of an AIX system I happen to have access to. Note the different location of the kernel from above:
$ file /usr/lib/boot/unix_up
/usr/lib/boot/unix_up: executable (RISC System/6000) or
object module not stripped
The information returned by the "file" command is from a file of its own, /etc/magic, which is several hundred lines long. However, the /etc/magic file only gives you information about the function of a particular file. This is done by reading the first few bytes of the file you asked about and comparing it with the known possibilities. It's not foolproof, but it's probably the closest thing to a Unix "file extension" capability.
In reality, there are only seven types of files on a Unix system, regardless of function. The following table lists the file types and the commands you can use to create and delete them:
| File Type |
Created Via: |
Remove Via: |
Symbol |
| Regular files |
almost any command |
rm |
- |
| Directories |
mkdir |
rmdir, rm -r |
d |
| Character device |
mknod |
rm |
c |
| Block device |
mknod |
rm |
b |
| Domain socket |
socket (a system call, not a command) |
rm |
s |
| Named pipe |
mknod |
rm |
p |
| Symbolic link |
ln |
rm |
l |
(As always, credit goes to the "Unix System Administration Handbook" for helping to flesh out the above list.)
Most system administration consists of manipulating the first two types: plain old files and directories. The last type, the symbolic link or "symlink," is the Unix equivalent of a Windows shortcut, although it merely links to a file, and doesn't carry any special environmental information as Windows shortcuts do. (For instance, a Windows shortcut can tell a program to start in a different directory, or with special options, which a Unix symlink can't.) Symlinks were originally used as a way to make files that resided on different physical filesystems accessible from more convenient locations, but nowadays you'll find symlinks scattered everywhere like kudzu.
The rest of the file types are known as "special" files. Device files are used in communication with the system's hardware and peripherals, while sockets and pipes are used in communication between processes running on the same system. Manipulating device files, sockets, and pipes goes far beyond the scope of this essay: They are installed with the operating system, or created by processes when necessary, and you don't often have to recreate them on a commercial Unix system (some Linux distributions may be a different story). However, be prepared to read a lot of documentation if you do have to create some of your own -- or to restore them from backup, which may be easier.
Although there are many ways to create files, you'll notice that there are only a few ways to remove them. This is because they all share one common characteristic: They're all just files. Everything in Unix is a file -- even a directory is just a special type of file. Whereas some Windows structures aren't mirrored in the filesystem -- some registry hives, for instance, get created dynamically at boot time -- pretty much everything on a Unix system has its avatar in the filesystem. The symbols listed in the above table are visible in the output of what will be one of your most frequently used commands: ls, short for "list files." With the "-l" switch, the command produces output like the following long-format listing of my password file. The symbol is the first character of the line, and shows that this is a regular file:
$ ls -l /etc/passwd
-rw-r-xr-- 1 root other 1203 Sep 16 05:05 passwd
Permissions
Claims that a given operating system is more or less secure than another often don't withstand scrutiny. All modern operating systems make provisions for security, which can be well or poorly implemented. However, there are distinct differences in the provisions.
Unix filesystem security is actually far simpler than the Windows security model. Since everything in Unix is a file, Unix security is almost exactly equivalent to filesystem security, and thus perhaps easier to implement (we're not talking about physical security, now). Windows security, on the other hand, is also concerned with access control on registry hives, Active Directory Objects, and so on. The simplicity of the Unix security model is also its strength, but because of the built-in limitations, minimizing your user and group layout as much as possible is usually beneficial.
The NT filesystem, NTFS, supports siix folder-level permissions via a mechanism known as Access Control Lists: Modify, Read, List Folder Contents, Read and Execute, Write, and Full Control. Those six permissions can be broken down further, into fourteen distinct permissions. Additionally, NTFS supports distinct levels of access to a given file for up to several thousand different users or groups.
Basic Unix supports only three distinct levels of access: for the owner of the file, for a group and for everyone. There are also the three premissions: read, write and execute. This is reflected in the previous file listing:
-rw-r-xr-- 1 root system 1203 Sep 16 05:05 passwd
The initial "-" indicates that this is a regular file. The next "rw-" indicates that the owner of the group, the root account, can read and write the file. The second "r-x" indicates that any member of the system group can read and execute the file. In fact, there's no need to be able to execute the password file, so I should delete the "x" permission using the command chmod, or "change mode," like this:
$ chmod g-x /etc/passwd
That subtracts (literally, "group minus execute") the execute permission from the group's permission string. A new listing of the file looks like this
-rw-r--r-- 1 root other 1203 Sep 16 05:05 passwd
You can obtain more information on the syntax of the chmod command, if you'll recall the discussion of manual pages from the last column. A similar command, chgrp, is used to change the user and group ownership of a file. Note that the user that owns the file doesn't have to be in the group that owns it, although that's usually the case.
The last three letters, "r--" indicate that anyone else on the system can read the file, but not write or execute it.
There are a few more important permissions. The setuid and setgid permissions, if set on an executable file, permit the system to execute that file as the user or group owning the file, thereby impersonating them and assuming all their privileges. This is a useful and dangerous capability. For instance, both permissions are set on the passwd command to allow users to change their own passwords without administrative intervention (note the "s" characters where the "x" permissions would normally be):
$ ls -l /bin/passwd
-r-s--s--x 2 root sys 101744 Jan 5 2000 /bin/passwd*
| Regarding Unto the Breach, Part I |
| Several readers of my last column quite rightly took me to task for my use of a cheap and ill-considered example (the methods available for removing files) when comparing the capabilities of Unix and NT, and seemed to consider it an aspersion on the capabilities of Windows system administrators in general, as though I was characterizing them all as thoughtless GUI-using clones. This was not my intention. Any expert Windows administrator must have more than a passing familiarity with the command line. I only intended to point out some potentially detrimental work habits, not to imply that they were universal to all administrators, but I remain convinced that Windows NT and its successors encourage dependency on their GUI interface -- in training, documentation, and implementation -- to a greater extent than many commercial Unices. However, Web-based administration tools and graphical installers for Unix are also proliferating like mad, so this is an industry-wide trend. Embedded Windows may not exhibit the same tendencies -- I would welcome some commentary on that topic. I hope the rest of this series proves more useful to the more seasoned Windows administrators out there. |
|
|
|
But, if you mistakenly set these permissions on something like a text editor, then any user would be capable of using that text editor to read, edit, and save files that you might not want them to. One of the best security practices you can employ is to reduce the number of setuid and setgid programs on your system, and to make sure that untrusted users can't upload them via the network or bring them in on floppy diskette or CD-ROM and wreak havoc.
Get to the Root
Even with the additional capabilities provided by setuid and setgid permissions, the Unix security model is all-or-nothing, to an extent. As a result, a great deal of emphasis is placed on protecting the root account, the equivalent of the Windows Administrator account. Additionally, most Unix implementations allow a person to be a member of only 16 groups, a far cry from several hundred permitted by Windows, and Unix groups may not be nested within one another. To allow for more granular delegation of control, some vendors extend the basic Unix permission scheme with access control lists. Solaris has an ACL implementation that can be layered atop the standard permissions; HP-UX has something similar. In practice, though, such extensions are rarely used, since most Unix administrators are interested in building and maintaining a set of cross-platform skills, and learning too many proprietary extensions can be limiting.
Next time, we'll go into more detail about users and groups, discover other ways to impersonate others, and talk a bit about how to configure the user environment and networking, time permitting.
Feedback on this column? Question for James? Post your comments below!
|
