Unix System Administration Assigning access rights
From "Migration",  Access to Wang, November 1993
[ Prior Article ]     [ Return to the Catalog of articles ]     [ Next Article ]

Unix has a reputation as an environment that is difficult to secure and maintain. In many ways, this notoriety is earned; there are more administration and security issues than for many other operating systems, and there are still few industry standards in administrative tools for Unix systems. The differences in setup between Unix sites is not hard to understand; consider how different Wang VS shops handle start procedures and menus.

While similar in concept, Unix system administration tasks are radically different from the norm of VS system administrators. One large difference is a general lack of tools: despite the efforts of hardware and software vendors, most Unix system administrators choose to use primitive techniques to accomplish their work, such as editing major system files with text editors or passing information through system commands.

This discussion is intended to give you an outline of practical approaches to Unix security and user administration - not as the final word on the subject. Consult other sources for other viewpoints on this complex topic, such as this month's Unix Bookshelf item.

Warning: Setting up users and assigning file permissions requires access to root privileges, also known as the superuser ID. Extreme caution must be exercised when using such an identity, since the cryptic power of Unix commands can result in wide- ranging and unanticipated results. It is best to use root privileges briefly and only for specific purposes, returning as soon as possible to an ID with less impact. Be careful!

Unix file security

System security in Unix systems revolves around assignment of file permissions - the access rights granted to users and groups. Unix files and directories can - and must - be protected against casual errors or deliberate sabotage. The Unix file system allows a great deal of control over user access through permissions, but it requires some care in design and implementation.

Unix file access permissions consist of three sections: user, group, and other (a.k.a. world). In turn, each section is composed of three access types: read, write, and execute. The sections and access type are shown on file listings as r, w, or x characters, indicating read, write, or execute access, or dashes, indicating no access. Figure One shows a "long" file listing, produced using the ls -la command; the access permissions are the ten characters on the far left of the listing.

The first character shows the type of file. In the example, .alias is a file (a dash indicates a file), while Mail is a directory. The files marked with periods (. and ..) are actually directories, representing the current directory and the directory above - an arrangement similar to the MS-DOS file system. The protections assigned to the directory above the current directory can be very important, since a lack of access rights above can prevent access to otherwise unprotected files below.

Reading from the second character, each group of three characters represents the three groups of users (user, group, world) and the corresponding access allowed. Thus, the .alias file has read, write, and execute access to user dsb (the owner) and only read access to members of the dp group and all other users.

How file protections are used

The operating system matches user permissions to the file or directory owner ID using the same method described above. If the test for ownership fails, the group memberships of the user are matched with the file or directory group. If the group test fails, the permissions granted to the world are reviewed. A failure at any of these levels stops the examination process and access to the file or directory is denied.

That last point is important: any failure as the tests are performed left to right results in denied access to the file. Since most users are members of more than one group, group tests can be difficult to predict; in the sample file listing, it appears from the files listed that user dsb is a member of the users, dp, and mail groups. Though absurd, it's nonetheless possible to set up file permissions such that everyone on earth other than the file's creator has full access rights. (Please don't ask me how I know this.)

In practice, most security is achieved through careful protection of directories. Since directories are files, they can be assigned protection in a similar manner as files. Protections work differently on directories, though; execute access means the ability to search ("stat") a directory, write access allows files to be created in that directory, and read access allows a file to be opened and, in some cases, its contents modified. It is common to protect a directory such that its contents are available to a user when the file is explicitly named, but the same user cannot list the contents of the directory. (MS-DOS systems often use hidden files or directories to accomplish this purpose.)

Applying permissions

File permissions are usually assigned to files and directories through the chmod (change file mode) utility. Changes to the files permissions can be made using two forms of nomenclature: through symbols or an octal number representing the bit pattern of each access. The octal designation assigns a value of 4 for read access, 2 for write access, and 1 for execute access; thus, the .profile file in Figure One could be said to have an access profile of 664. As another example, the commands chmod -x scripts and chmod 666 scripts would have the same affect on the scripts file in the sample listing, removing execute access from the file.

File ownership is assigned through the chown (change owner) and chgrp (change group) commands. Executing the command chown xyz a.FILE.name changes the file's ownership to user xyz, while the command chgrp slugs userfile changes the group association of userfile to slugs. Following this example further, user dsb - a member of the users, dp, and mail groups - would still have read access to a.FILE.name (as a member of the dp group) and full access to userfile (as the file's owner).

Setting up new users

The process of setting up new users on Unix systems is conceptually similar for all environments, but differences in the site's needs and system administration software provided by vendors make it different in practice. The tasks include adding a user ID to the /etc/passwd and /etc/group files (the account information), setting up a home directory for the user, and establishing the user's environment and defaults. This compares to similar tasks on the VS, where account information is maintained by the SECURITY utility and each site uses start procedures to set defaults and fire up the first application.

The /etc/passwd file stores the user's initials, full name, primary group affiliation, shell (command environment, and password. In most Unix shops the user's initials are used as an ID, but each user must also be identified by a unique number. The user's primary group is also identified by number, not name. Finally, the user's password is encoded within this file - a task performed through the passwd command. The file consists of several variable-length data fields, separated by colons. Many Unix system administrators maintain the /etc/passwd and /etc/group files using text editors - a dangerous but common practice.

Unix systems require a unique directory for each user - their home directory. Typical home directory names include /users/dsb, /u/dsb, or /home/dsb, with the name difference primarily a matter of culture and convention. The home directory must be protected so that only the user may have access to it, and one or more initialization files may be copied to the home directory or created for the user. Examples of these initialization files from the listing in Figure One include: .profile, the master profile for the user and the first item run after logon; .exrc, a set of preferences for the vi editor; and .alias, a collection of replacement commands that personalizes the command environment.

Conclusion

The subjects of Unix security and user setup are complex and deserves more coverage than is available here. Practice and experience are the best trainers, and mistakes are inevitable. If possible, do your learning in a non-production environment - such as within a Unix-like PC environment or a standalone workstation.

Unix Bookshelf

Essential System Administration
AEleen Frisch
O'Reilly & Associates, Inc., Sebastopol, CA; 1991

Level-headed system administration information with interesting comparisons between BSD and AT&T versions of Unix and several of the menu-driven system administration tools provided by vendors.

Figure 1: Sample Unix Directory Listing

total 208 drwx------ 15 dsb dp 2048 Jul 11 10:21 . drwxr-xrwx 163 sys sys 6144 Jul 8 10:59 .. -rwxr--r-- 1 dsb dp 748 May 4 05:48 .alias -rw-r--r-- 1 dsb users 360 Oct 21 1992 .exrc -rw-r--r-- 1 dsb dp 0 May 13 1992 .news_time -rw-rw-r-- 1 dsb dp 922 Jul 11 10:48 .profile -rwxr--r-- 1 dsb dp 12 Jun 4 07:18 a.FILE.name drwx------ 2 dsb mail 64 May 21 1992 Mail drwxrwxrwx 2 dsb dp 1024 Jun 7 23:01 scripts drwxrwxr-x 2 dsb users 44032 Jul 9 18:34 temp -rwxrw-r-- 1 dsb users 748 Jun 4 07:18 userfile drwxrwxr-x 2 dsb users 1024 Jul 9 14:34 work