Chapter 13. Users, Groups, and Permissions
| IN THIS CHAPTER
Users and file permissions are the concepts that form the central pillars of a UNIX system. Working within a system that is designed for multiuser operation imposes many more rules and restrictions than you experience when administering single-user desktop systems. This is a safety feature as much as a matter of privacy: not only can each user hide his files and sensitive data from the prying eyes of other users, but each user is also restricted from altering parts of the system that he does not himself own. This protects the components and configuration of the operating system itself from being harmed by the actions of casual users, whether maliciously or accidentally. A true multiuser operating system is one where every process is owned by a particular user identity, each of which has a certain level of privileges with which those processes can be executed. You might already be familiar with operating a desktop computer in a multiuser context; however, even in the modern server-class iterations of Windows, user privileges play a somewhat different role than in FreeBSD. Let's look at why this is the case, using Windows' incremental development to illustrate by contrast how user permissions are used in FreeBSD. Traditional desktop operating systems, such as Windows 95/98/Me and classic Mac OS, gave the impression of being multiuser operating systems; however, strictly speaking, they were not. What they used, instead, were simply profiles, or ways of presenting data according to each user's preferences. Any potentially system-altering action the user wanted to take on the local machine, such as reading and writing files, installing programs, or shutting down the computer, was permitted because there was only one "user" with absolute control over the machine. Access to network resources was done on a "guest user" basis, without the user or the machine participating in any true authentication with a domain controller or its equivalent. Windows NT, 2000, and XP, as server-class operating systems with a need for greater data security and stability than their predecessors, have taken successive steps toward becoming true multiuser operating systems like FreeBSD. Each user in the system has a separate account and a set of permissions that control access to files, printers, and other resources. Windows and FreeBSD both have the concept of a "root" user, or administrator, who has absolute power over the local machine. Both systems have groups (enabling sets of users to have the same access to certain resources) and different layers of accessibility. (In fact, Windows-style permissions have such complexityinheritance upward, inheritance downward, domain users versus local users, and up to three accounts with administrative powerthat even the most experienced user can get swamped.) However, even with all the recent advances that bring Windows' multiuser feature set near to that of UNIX, the two systems still come from very different remote-accessibility and administration traditions that continue to influence how each one's permissions models work, leading to many fundamental differences that persist today. Note Mac OS X, a true UNIX operating system, has a multiuser architecture similar to FreeBSD'sexcept that it's designed not to allow you to run a user session with root privileges. Instead, administrative actions are executed under the sudo model, where the system prompts you to enter your password to authenticate yourself as a user who's allowed to attain administrative privileges (and not just someone who happened to sit down at a logged-in user's session). The system then retains this elevated level of privileges for the duration of whatever administrative action you're performing. The sudo model is a far safer way of administering a system than running as root all the time, and you should consider installing the sudo program (in the security category of the ports or packages) and using it instead of running as root wherever possible. Set up the sudoers file as directed in the man page for sudo, to restrict access to the command to authorized users. Then, prefix a command with sudo to be prompted for the root password and have the command executed as root. Although modern versions of Windows feature integrated graphical terminal-server software, the traditional method for using and administrating a Windows system is to do so at the console, with the user sitting in front of the actual computer. Indeed, because of the high network overhead and potential security implications of graphical terminal server software, many administrators still tend to prefer using the console, where the complex user interface doesn't suffer from network lag. In the case of servers in which user privileges are important, network applications running on Windows typically consist of two portions: a server, which handles all the central processing and is running at all times, and a client, which must be installed on a remote computer and accesses the server application through whatever functions are programmed into the client. A web browser accessing a server is a prime example of this, as is an email client accessing POP or IMAP mail or calendaring data. The web or email server application runs only under its own restrictive permissions, and each user accessing the application from a remote computer is bound by those same restrictions and can't directly affect any files on the server. If data must be divided among users and kept private and secure, that division is typically handled within the application itself, not by the operating system. FreeBSD and other UNIX-style operating systems, by contrast, thrive on ad-hoc remote accessibility. Although client-server applications are as common in the UNIX world as under Windows, in UNIX it's far more crucial for remote users to be able to access the entire operating system through terminal connections (such as Telnet or SSH), which provide a user with a command-line shell interface over the network. Shell access is very lightweight and does not require any more than the most rudimentary of client applications, which are often already installed as part of the client operating system. As you have already seen, a shell gives a user the ability to issue any FreeBSD commands she wants, rather than just what commands are permitted by the specialized client software for a particular application, and the simple textual interface isn't as sensitive to network-related sluggishness as a graphical remote-access client that has to transmit all kinds of information about the movements of the windowing system. The upshot of this is that beyond the usual client-server applications like web servers and email, your FreeBSD machine will likely be accessed from many remote locations and by many different users at once, all using terminal programs to run shells on the server itself, issuing all kinds of different commands to directly modify files on the server. On FreeBSD systems, therefore, user and group permissionswhich protect critical system files and provide user data privacy during this ad-hoc accessplay a much more important part in an administrator's life than they would on a Windows system, in which the administrator can always predict which applications will be running and how they might affect the system. Caution SSH (Secure Shell) is an encrypted, or "scrambled," form of remote terminal connection. It provides all the functionality of Telnet (the traditional clear-text terminal application), with added security to prevent eavesdroppers from viewing terminal traffic such as your password or sensitive system data. Today, SSH is preferred and encouraged in almost all circumstances, and Telnet should only be used when SSH is not an option. We will cover SSH in more detail in Chapter 30, "Network Security." |
