Running Linux, 5th Edition - Matthias Kalle Dalheimer [208]
The /etc/inetd.conf file represents a more complicated way of running programs—another level of indirection. The idea behind /etc/inetd.conf is that it would waste a lot of system resources if a dozen or more daemons were spinning idly, waiting for a request to come over the network. So, instead, the system starts up a single daemon named inetd. This daemon listens for connections from clients on other machines, and when an incoming connection is made, it starts up the appropriate daemon to handle it. For example, when an incoming FTP connection is made, inetd starts up the FTP daemon (ftpd) to manage the connection. In this way, the only network daemons running are those actually in use.
There's a daemon for every service offered by the system to other systems on a network: fingerd to handle remote finger requests, rwhod to handle rwho requests, and so on. A few daemons also handle non-networking services, such as kerneld, which handles the automatic loading of modules into the kernel. (In Versions 2.4 and up, this is called kmod instead and is no longer a process, but rather a kernel thread.)
Chapter 11. Managing Users, Groups, and Permissions
Managing User Accounts
Even if you're the only actual human being who uses your Linux system, understanding how to manage user accounts is important—even more so if your system hosts multiple users.
User accounts serve a number of purposes on Unix systems. Most prominently, they give the system a way to distinguish between different people who use the system for reasons of identification and security. Each user has a personal account with a separate username and password. As discussed in "File Ownership and Permissions," later in this chapter, users may set permissions on their files, allowing or restricting access to them by other users. Each file on the system is "owned" by a particular user, who may set the permissions for that file. User accounts are used to authenticate access to the system; only those people with accounts may access the machine. Also, accounts are used to identify users, keep system logs, tag electronic mail messages with the name of the sender, and so forth.
Apart from personal accounts, there are users on the system who provide administrative functions. As we've seen, the system administrator uses the root account to perform maintenance—but usually not for personal system use. Such accounts are accessed using the su command, allowing another account to be accessed after logging in through a personal account.
Other accounts on the system may not involve human interaction at all. These accounts are generally used by system daemons , which must access files on the system through a specific user ID other than root or one of the personal user accounts. For example, if you configure your system to receive a newsfeed from another site, the news daemon must store news articles in a spool directory that anyone can access but only one user (the news daemon) can write to. No human being is associated with the news account; it is an "imaginary" user set aside for the news daemon only.
One of the permission bits that can be set on executables is the setuid bit, which causes the program to be executed with the permissions of the owner of that file. For example, if the news daemon were owned by the user news, and the setuid bit were set on the executable, it would run as if by the user news. news would have write access to the news spool directory, and all other users would have read access to the articles stored there. This is a security feature. News programs can give users just the right amount of access to the news spool directory, but no one can just play around there.
As the system administrator, it is your job to create and manage accounts for all users (real and virtual) on your machine. This is actually a painless, hands-off task in most cases, but it's important to understand how it works.
The passwd File