Besides its native operating mode, bash can also be switched into POSIX mode. The POSIX (Portable Operating System Interface) standard, described in detail in Appendix A, defines guidelines for standardizing UNIX. One part of the POSIX standard covers shells.

bash is nearly 100% POSIX-compliant in its native mode. If you want strict POSIX adherence, you can either start bash with the —posix option, or set it from within the shell with set -o posix.

Only in very rare circumstances would you ever have to use POSIX mode. The differences, outlined in Appendix A, are small and are mostly concerned with the command lookup order and how functions are handled. Most bash users should be able to get through life without ever having to use this option.

bash has several command-line options that change the behavior of and pass information to the shell. The options fall into two sets: single character options, like we’ve seen in previous chapters of this book, and multicharacter options, which are a relatively recent improvement to UNIX utilities.^[5] Table 10-1 lists all of the options.^[6]

The multicharacter options have to appear on the command line before the single-character options. In addition to these, any set option can be used on the command line. Like shell built-ins, using a + instead of - turns an option off.

Of these options, the most useful are -i (interactive), -r (restricted), -s (read from standard input), -p (privileged), and -m (enable job control). Login shells are usually run with the -i, -s, and -m flags. We’ll look at restricted and privileged modes later in this chapter.

umask, like the same command in most other shells, lets you specify the default permissions that files have when users create them. It takes the same types of arguments that the chmod command does, i.e., absolute (octal numbers) or symbolic permission values.

The umask contains the permissions that are turned off by default whenever a process creates a file, regardless of what permission the process specifies.^[8]

We’ll use octal notation to show how this works. As you probably know, the digits in a permission number stand (left to right) for the permissions of the owner, owner’s group, and all other users, respectively. Each digit, in turn, consists of three bits, which specify read, write, and execute permissions from left to right. (If a file is a directory, the “execute” permission becomes “search” permission, i.e., permission to cd to it, list its files, etc.)

For example, the octal number 640 equals the binary number 110 100 000. If a file has this permission, then its owner can read and write it; users in the owner’s group can only read it; everyone else has no permission on it. A file with permission 755 gives its owner the right to read, write, and execute it and everyone else the right to read and execute (but not write).

022 is a common umask value. This implies that when a file is created, the “most” permission it could possibly have is 755—which is the usual permission of an executable that a compiler might create. A text editor, on the other hand, might create a file with 666 permission (read and write for everyone), but the umask forces it to be 644 instead.

The ulimit command was originally used to specify the limit on file creation size. But bash’s version has options that let you put limits on several different system resources. Table 10-2 lists the options.

Each takes a numerical argument that specifies the limit in units shown in the table. You can also give the argument “unlimited” (which may actually mean some physical limit), “hard” and “soft”, which refer to the current hard and soft limits (see below), or you can omit the argument, in which case it will print the current limit. ulimit -a prints limits (or “unlimited”) of all types.^[10] You can specify only one type of resource at a time. If you don’t specify any option, -f is assumed.

Some of these options depend on operating system capabilities that don’t exist in older UNIX versions. In particular, some older versions have a fixed limit of 20 file descriptors per process (making -n irrelevant), and some don’t support virtual memory (making -v irrelevant).

The -d and -s options have to do with dynamic memory allocation, i.e., memory for which a process asks the operating system at runtime. It’s not necessary for casual users to limit these, though software developers may want to do so to prevent buggy programs from trying to allocate endless amounts of memory due to infinite loops.

The -v and -m options are similar; -v puts a limit on all uses of memory, and -m limits the amount of physical memory that a process is allowed to use. You don’t need these unless your system has severe memory constraints or you want to limit process size to avoid thrashing.

The -u option is another option which is useful if you have system memory constraints or you wish just wish to stop individual users from hogging the system resources.

You may want to specify limits on file size (-f and -c) if you have constraints on disk space. Sometimes users actually mean to create huge files, but more often than not, a huge file is the result of a buggy program that goes into an infinite loop. Software developers who use debuggers like sdb, dbx, and gdb should not limit core file size, because core dumps are necessary for debugging.

The -t option is another possible guard against infinite loops. However, a program that is in an infinite loop but isn’t allocating memory or writing files is not particularly dangerous; it’s better to leave this unlimited and just let the user kill the offending program.

In addition to the types of resources you can limit, ulimit lets you specify hard or soft limits. Hard limits can be lowered by any user but only raised by the super user (root); users can lower soft limits and raise them—but only as high as the hard limit for that resource.

If you give -H along with one (or more) of the options above, ulimit will set hard limits; -S sets soft limits. Without either of these, ulimit sets the hard and soft limit. For example, the following commands set the soft limit on file descriptors to 64 and the hard limit to unlimited:

ulimit -Sn 64
ulimit -Hn unlimited

When ulimit prints current limits, it prints soft limits unless you specify -H.

The best possible approach to globally available customization would be a system-wide environment file that is separate from each user’s environment file—just like /etc/profile is separate from each user’s .bash_profile. Unfortunately, bash doesn’t have this feature.

Nevertheless, the shell gives you a few ways to set up customizations that are available to all users at all times. Environment variables are the most obvious; your /etc/profile file will undoubtedly contain definitions for several of them, including PATH and TERM.

The variable TMOUT is useful when your system supports dialup lines. Set it to a number N, and if a user doesn’t enter a command within N seconds after the shell last issued a prompt, the shell will terminate. This feature is helpful in preventing people from “hogging” the dialup lines.

You may want to include some more complex customizations involving environment variables, such as the prompt string PS1 containing the current directory (as seen in Chapter 4).

You can also turn on options, such as emacs or vi editing modes, or noclobber to protect against inadvertent file overwriting. Any shell scripts you have written for general use also contribute to customization.

Unfortunately, it’s not possible to create a global alias. You can define aliases in /etc/profile, but there is no way to make them part of the environment so that their definitions will propagate to subshells. (In contrast, users can define global aliases by putting their definitions in ~/.bashrc.)

However, you can set up global functions. These are an excellent way to customize your system’s environment, because functions are part of the shell, not separate processes.

The restricted shell is designed to put the user into an environment where her ability to move around and write files is severely limited. It’s usually used for “guest” accounts.^[11] You can make a user’s login shell restricted by putting rbash in the user’s /etc/passwd entry.^[12]

The specific constraints imposed by the restricted shell disallow the user from doing the following:

These restrictions go into effect after the user’s .bash_profile and environment files are run. In addition, it is wise to change the owner of the users’ .bash_profile and .bashrc to root, and make these files read-only. The users’ home directory should also be made read-only.

This means that the restricted shell user’s entire environment is set up in /etc/profile and .bash_profile. Since the user can’t access /etc/profile and can’t overwrite .bash_profile, this lets the system administrator configure the environment as he sees fit.

Two common ways of setting up such environments are to set up a directory of “safe” commands and have that directory be the only one in PATH, and to set up a command menu from which the user can’t escape without exiting the shell.

Before we explain the other security features, here is some background information on system security that should help you understand why they are necessary.

Many problems with UNIX security hinge on a UNIX file attribute called the suid (set user ID) bit. This is like a permission bit (see umask earlier in this chapter): when an executable file has it turned on, the file runs with an effective user ID equal to the owner of the file, which is usually root. The effective user ID is distinct from the real user ID of the process.

This feature lets administrators write scripts that do certain things that require root privilege (e.g., configure printers) in a controlled way. To set a file’s suid bit, the superuser can type chmod 4755 filename; the 4 is the suid bit.

Modern system administration wisdom says that creating suid shell scripts is a very, very bad idea.^[13] This has been especially true under the C shell, because its .cshrc environment file introduces numerous opportunities for break-ins. bash’s environment file feature creates similar security holes, although the security feature we’ll see shortly make this problem less severe.

We’ll show why it’s dangerous to set a script’s suid bit. Recall that in Chapter 3, we mentioned that it’s not a good idea to put your personal bin directory at the front of your PATH. Here is a scenario that shows how this placement combines with suid shell scripts to form a security hole: a variation of the infamous “Trojan horse” scheme. First, the computer cracker has to find a user on the system with an suid shell script. In addition, the user must have a PATH with her personal bin directory listed before the public bin directories, and the cracker must have write permission on the user’s personal bin directory.

Once the cracker finds a user with these requirements, he follows these steps:

The one way to protect against Trojan horses is privileged mode. This is a set -o option (set -o privileged or set -p).

In privileged mode, when an suid bash shell script is invoked, the shell does not run the user’s environment file—i.e., it doesn’t expand the user’s BASH_ENV environment variable.

Since privileged mode is an option, it is possible to turn it off with the command set +o privileged (or set +p). But this doesn’t help the potential system cracker: the shell automatically changes its effective user ID to be the same as the real user ID—i.e., if you turn off privileged mode, you also turn off suid.

Privileged mode is an excellent security feature; it solves a problem that originated when the environment file idea first appeared in the C shell.

Nevertheless, we still strongly recommend against creating suid shell scripts. We have shown how bash protects against break-ins in one particular situation, but that certainly does not imply that bash is “safe” in any absolute sense. If you really must have suid scripts, you should carefully consider all relevant security issues.

Finally, if you would like to learn more about UNIX security, we recommend Practical UNIX and Internet Security, by Gene Spafford and Simson Garfinkel (O’Reilly ).