The /etc/passwd File

The /etc/passwd file stores the user’s login, encrypted password entry, UID, default GID, name (sometimes called GECOS), home directory, and login shell. Each line in the file represents information about a user. The lines are made up of various standard fields, with each field delimited by a colon


Username Field
This field is also referred to as the login field or the account field. It stores the name of the user on the system. The username must be a unique string and uniquely identifies a user to the system. Different sites use different methods for generating user login names. A common method is to use the first letter of the user’s first name and append the user’s last name. This usually works, because the chances are relatively slim that one would have users with the same first and last names. There are, of course, several variations of this method. For example, for a user whose first name is “Ying” and whose last name is “Yang”—a username of “yyang” can be assigned to that user.


Password Field
This field contains the encrypted password for the user. On most modern Linux systems, this field contains a letter x to indicate that shadow passwords are being used on the system. Every user account on the system should have a password or, at the very least, be tagged as impossible to log in. This is crucial to the security of the system—weak passwords make compromising a system just that much simpler.

The original philosophy behind passwords is actually quite interesting, especially since we still rely on a significant part of it today. The idea is simple: Instead of relying on protected files to keep passwords a secret, the system would encrypt the password using an AT&T-developed (and National Security Agency–approved) algorithm called Data Encryption Standard (DES) and leave the encrypted value publicly viewable. What originally made this secure was that the encryption algorithm was computationally difficult to break. The best most folks could do was a brute-force dictionary attack, where automated systems would iterate through a large dictionary and rely on the nature of users to pick English words for their passwords. Many people tried to break DES itself, but since it was an open algorithm that anyone could study, it was made much more bulletproof before it was actually deployed.

When users entered their passwords at a login prompt, the password they entered would be encrypted. The encrypted value would then be compared against the user’s password entry. If the two encrypted values matched, the user was allowed to enter the system. The actual algorithm for performing the encryption was computationally cheap enough that a single encryption wouldn’t take too long. However, the tens of thousands of encryptions that would be needed for a dictionary attack would take prohibitively long. But then a problem occurred: Moore’s Law on processor speed doubling every 18 months held true, and home computers were becoming powerful and fast enough that programs were able to perform a brute-force dictionary attack within days rather than weeks or months. Dictionaries got bigger, and the software got smarter. The nature of passwords thus needed to be reevaluated. One solution has been to improve the algorithm used to perform the encryption of passwords. Some distributions of Linux have followed the path of the FreeBSD operating system and used the Message-Digest algorithm 5 (MD5) scheme. This has increased the complexity involved in cracking passwords, which, when used in conjunction with shadow passwords (discussed later on), works quite well. (Of course, this is assuming you make your users choose good passwords!)


User-ID Field (UID)
This field stores a unique number that the operating system and other applications use to identify the user and determine access privileges. It is the numerical equivalent of the Username field. The UID must be unique for every user, with the exception of the UID 0 (zero). Any user who has a UID of 0 has root (administrative) access and thus has the full run of the system. Usually, the only user who has this specific UID has the login root. It is considered bad practice to allow any other users or usernames to have a UID of 0. This is notably different from the Windows NT and 2000 models, in which any number of users can have administrative privileges. Different Linux distributions sometimes adopt different UID numbering schemes. For example, Fedora and Red Hat Enterprise Linux (RHEL) reserve the UID 99 for the user “nobody,” while SuSE and Ubuntu Linux use the UID 65534 for the user “nobody.”


Group-ID Field (GID)
The next field in the /etc/passwd file is the group-ID entry. It is the numerical equivalent of the primary group that the user belongs to. This field also plays an important role in determining user access privileges. It should be noted that besides a user’s primary group, a user can belong to other groups as well.


GECOS
This field can store various pieces of information for a user. It can act as a placeholder for the user description, full name (first name and last name), telephone number, and so on. This field is optional and as result can be left blank. It is also possible to store multiple entries in this field by simply separating the different entries with a comma.


Directory
This is usually the user’s home directory, but it can also be any arbitrary location on the
system. Every user who actually logs into the system needs a place for configuration files
that are unique to the user. This place, called a home directory, allows each user to work
in a customized environment without having to change the environment customized by another user—even if both users are logged into the system at the same time. In this directory, users are allowed to keep not only their configuration files, but their regular work files as well.

For the sake of consistency, most sites place home directories at /home and name each user’s directory by that user’s login name. Thus, for example, if your login name were “yyang,” your home directory would be /home/yyang. The exception to this is for some special system accounts, such as a root user’s account or a system service. The superuser’s (root’s) home directory in Linux is usually set to /root (but for most variants of UNIX, such as Solaris, the home directory is traditionally /). An example of a special system service that might need a specific working directory could be a web server whose web pages are served from the /var/www/ directory. In Linux, the decision to place home directories under /home is strictly arbitrary, but it does make organizational sense. The system really doesn’t care where we place home directories, so long as the location for each user is specified in the password file.


Shell
When users log into the system, they expect an environment that can help them be productive. This first program that users encounter is called a shell. If you’re used to the Windows side of the world, you might equate this with command.com, Program Manager, or Windows Explorer (not to be confused with Internet Explorer, which is a web rowser). Under UNIX/Linux, most shells are text-based. A popular default user shell in Linux is the Bourne Again Shell, or BASH for short. Linux comes with several shells from which to choose—you can see most of them listed in the /etc/shells file. Deciding which shell is right for you is kind of like choosing a favorite beer—what’s right for you isn’t right for everyone, but still, everyone tends to get defensive about their choice! What makes Linux so interesting is that you do not have to stick with the list of shells provided in /etc/shells. In the strictest of definitions, the password entry for each user doesn’t list what shell to run so much as it lists what program to run first for the user. Of course, most users prefer that the first program run be a shell, such as BASH.

Source of Information : McGraw Hill Osborne Media Linux Administration A Beginners Guide Fifth Edition