The /etc/passwd File
On most Unix systems the user accounts are listed in the database file /etc/passwd; the corresponding passwords for these
accounts are kept in a file named /etc/shadow, /etc/security/passwd, or /etc/master.passwd. To improve lookup
speed, some systems compile the password file into a compact index file named something like /etc/pwd.db, which is used instead.
In general, after, say, 1K user you need something better that a text file. But most server contain less the a hundred accounts. For
them passwd files is "perfect" it is simple, reliable (stored locally so it does not depend on the availability of network)
and can be synchronized/distributed with/to multiples servers, if necessary. More complex alternative authentication scheme
such as Kerberos or Active directory are often an overkill in such cases.
The /etc/passwd file contains basic user attributes. This is an ASCII file that contains a line for each user. Each
entry consists of seven fields
- Username: It is used when user logs in. It should be between 1 and 32 characters in length.
- Password: This field is no longer used for its initial purpose and usually contains character 'x'. This character
indicates that encrypted password is stored in /etc/shadow file. Please note that you need to use the passwd command to computes
the hash of a password typed at the CLI or to store/update the hash of the password in /etc/shadow file. On Linux systems, setting
this field to an asterisk ("*") is a common way to disable direct logins to an account while still preserving its name, while another
possible value is "*NP*" which indicates to use an
NIS server to obtain
- User ID (UID): Each user must be assigned a user ID (UID). UID 0 (zero) is reserved for root and UIDs 1-99 are
reserved for other predefined accounts. Further UID 100-999 are reserved by system for administrative and system accounts/groups.
- Group ID (GID): The primary group ID (stored in /etc/group file)
- Gecos field, commentary that describes the
person or account. Typically, this is a set of comma-separated values including the user's full name and contact details.
- Home directory: The absolute path to the directory the user will be in when they log in. If this directory does
not exists then this user home directory becomes /
- Command/shell: Program that is started every time the user logs into the system. For an interactive user, this
is usually one of the system's
interpreters (shells). Typically this
is the absolute path of a command or shell (/bin/bash). But please note that it does not have to be a shell. You can create account
logging into which just executes a specific command without giving the user of this account login shell.
Here is an example of an /etc/passwd file from a Red Hat 5.8 system containing a variety of system and ordinary users:
vcsa:x:69:69:virtual console memory owner:/dev:/sbin/nologin
dbus:x:81:81:System message bus:/:/sbin/nologin
rpc:x:32:32:Portmapper RPC user:/:/sbin/nologin
oprofile:x:16:16:Special user account to be used by OProfile:/home/oprofile:/sbin/nologin
rpcuser:x:29:29:RPC Service User:/var/lib/nfs:/sbin/nologin
nfsnobody:x:65534:65534:Anonymous NFS User:/var/lib/nfs:/sbin/nologin
xfs:x:43:43:X Font Server:/etc/X11/fs:/sbin/nologin
There is generally nothing special about any Unix account name. All Unix privileges are determined by the UID plus the group ID,
or GID. Account name is just a label for UID, a numeric value. For example, an account with name root and UID 1005 would have
no special privileges, but an account named lowlyuser with UID 0 would be a superuser.
In general, you should avoid creating users with a UID of 0 other than root, and you should avoid using the name root
for a regular user account. So in most case when people talk about account "root" or "superuser" account this is an account with
the UID of 0.
Unix keeps the mapping between usernames and UIDs in the file /etc/passwd. Each user's UID is stored in the field after
the one which in the past contained the user's encrypted password (and still contain in case on NIS users).
The UID is the actual information that the operating system uses to identify the user; usernames are provided merely as a convenience
for humans. If two users are assigned the same UID, Unix views them as the same user, even if they have different usernames and passwords.
Two users with the same UID can freely read and delete each other's files and can kill each other's running programs. Giving two users
the same UID is almost always a bad idea; it is better to create multiple users and put them in the same group.
Conversely, files can be owned by a UID that is not listed in /etc/passwd and do not have an associated username.
This is a typical situation when the user was deleted but some of his/her files stayed. This is actually a sign of sloppy system administration.
If a user is added to /etc/passwd in the future with that UID, that user will suddenly become the owner of the files,
which might be not a good idea.
From passwd - Wikipedia
/etc/shadow is used to increase the security level of passwords by restricting all but highly privileged users' access
to hashed password data. Typically, that data is kept in files owned by and accessible only by the
Systems administrators can reduce the likelihood of brute-force attacks by making the list of hashed passwords unreadable by unprivileged
users. The obvious way to do this is to make the
passwd database itself readable only by the root user. However, this would
restrict access to other data in the file such as username-to-userid mappings, which would break many existing utilities and provisions.
One solution is a "shadow" password file to hold the password hashes separate from the other data in the world-readable passwd
file. For local files, this is usually
/etc/shadow on Linux
and Unix systems, or
/etc/master.passwd on BSD systems; each is readable only by
root. (Root access to the data is considered acceptable since on systems with the traditional
"all-powerful root" security model, the root user would be able to obtain the information in other ways in any case). Virtually all
recent Unix-like operating systems use shadowed passwords.
The shadow password file does not entirely solve the problem of attacker access to hashed passwords, as some network authentication
schemes operate by transmitting the hashed password over the network (sometimes in
making it vulnerable to interception. Copies of system data, such as system backups written to tape or optical media, can also become
a means for illicitly obtaining hashed passwords. In addition, the functions used by legitimate password-checking programs need to be
written in such a way that malicious programs cannot make large numbers of authentication checks at high rates of speed.
Regardless of whether password shadowing is in effect on a given system, the passwd file is readable by all users so that various
system utilities (e.g., ls) can work (e.g., to ensure that user names are
shown when the user lists the contents of a folder), while only the root user can write to it. Without password shadowing, this means
that an attacker with unprivileged access to the system can obtain the hashed form of every user's password. Those values can be used
to mount a brute force attack
offline, testing possible passwords against the hashed passwords relatively quickly without alerting system security arrangements designed
to detect an abnormal number of failed
attempts. Especially when the hash is not salted it is also possible to look up these hashed passwords in
rainbow tables, databases specially made for giving
back a password for a unique hash.
With a shadowed password scheme in use, the
/etc/passwd file typically shows a character such as '
x' in the password field for each user instead of the hashed password, and
/etc/shadow usually contains the
following user information:
- User login name
- salt and hashed password OR a status
exception value e.g.:
- "$id$salt$hashed", the printable form of a password hash as produced by
crypt (C), where "$id" is the algorithm used. On GNU/Linux,
$1$" stands for MD5, "
Blowfish (correct handling of 8-bit chars),
$5$" is SHA-256 and "
other Unix may have different values, like
Key stretching is used to increase
password cracking difficulty, using by
default 1000 rounds of modified MD5,
64 rounds of Blowfish, 5000 rounds of SHA-256 or SHA-512.
The number of rounds may be varied for
Blowfish, or for
SHA-256 and SHA-512 by using e.g. "$6$rounds=50000$".
- Empty string – No password, the account has no password (reported by passwd on Solaris with "NP").
- "!" – the account is password locked, user will be unable to log in via password authentication but other methods (e.g. ssh
key) may be still allowed.
- "*LK*" or "*" – the account is locked, user will be unable to log in via password authentication but other methods (e.g. ssh
key) may be still allowed.
- "!!" – the password has never been set (RedHat)
- Days since epoch of last password change
- Days until change allowed
- Days before change required
- Days warning for expiration
- Days before account inactive
- Days since epoch when account expires
The format of the shadow file is simple, and basically identical to that of the password file, to wit, one line per user, ordered
fields on each line, and fields separated by colons. Many systems require the order of user lines in the shadow file be identical to
the order of the corresponding users in the password file.
Every Unix user belongs to one or more groups. As with user accounts, groups have both a group name and a group identification
number (GID). GID values are also historically 16-bit integers, but many systems now use 32-bit integers for these, too.
As the name implies, Unix groups are used to group users together. As with usernames, group names and numbers are assigned by the
system administrator when each user's account is created. Groups can be used by the system administrator to designate sets of users
who are allowed to read, write, and/or execute specific files, directories, or devices.
Each user belongs to a primary group that is stored in the /etc/passwd file. The GID of the user's
primary group follows the user's UID. Historically, every Unix user was placed in the generic group users, which had a GID of 100. These
days, however, most Unix sites place each account in its own group. This results in decreased sharing, but somewhat better
security and flexibility for sysadmin:
The advantage of assigning each user his own group is that it allows users to have a unified umask of 007 in all instances. When
users wish to restrict access of a file or directory to themselves, they leave the group set to their individual group. When they
wish to open the file or directory to members of their workgroup or project, all they need to do is to change the file's or directory's
Consider, again, our /etc/passwd example:
In this example, primary GID is 9262 which might be the badge number for this particular user. Generally it makes sense to
assign users unique UID and promary group id and maintenance consistency between multiple servers. This simplify transfer of files between
server -- they will automatically owned by the same user.
Groups provide a handy mechanism for providing a subset of users on a particular server access to some set of files. For example,
you might want to set up a group for a team of researchers working on a project (for example decoding of genome), so that only
researchers from this group, but nobody else,
can read and modify the team's files.
Groups can also be used to restrict access to sensitive information or specially licensed applications to a particular set of users:
for example, many Unix computers are set up so that only users who belong to the kmem group can examine the operating system's kernel
Similarly user wheel group usually list users who have root access to the system with the first one considered to be "primary
system administrator" for the particular server. In case datacenter has a thousand of server that greatly simplify determining who need
to contacted for the particular server problems even if the person who discovered the problem does not have access to spreadsheet or
database with the servers assignment for syadmin group. In a large coporation when a ticket can travel in the helpdesk jungles
for a week or so that increase chances that the user or server problem will be resolved promptly.
You can also have a group tempadmin which are people who need root access for specific and short period of time. You
can grand them access to root via sudo and schedule at command for the end of the period that automatically removes the user
from this group.
The operator group is commonly used to allow only specific users to perform operation with media such as DVD, USB flash
drives, as well as the tape backup system, which may have "read" access to the system's raw disk devices.
And a privileged group might be limited to people who have signed nondisclosure forms so they can view the source code for
RHEL supports mandatory access controls (MAC), which have controls based on data labeling in addition to the traditional Unix discretionary
access controls (DAC).
This system called SE linux is often disabled for internal "infrastructure" servers, as it complicated things, but should be enabled
for all server facing Internet.
The /etc/group file contains the database that lists every group on your computer and its corresponding GID. Its format
is similar to the format used by the /etc/passwd file.
bezroun@lustwz54: $ cat /etc/group
One important group is the Wheel Group.
Group's "password" (obsolite)
List of the users who are in the group
Most versions of Unix use the wheel group as the list of all of the computer's system administrators (in this case, bezroun
and the root user are the only members). On some systems, the group has a GID of 10; on other systems, the group has a GID of 15. Unlike
a UID of 0, a GID of 0 is usually not significant. However, the name wheel is very significant: on many
systems the use of the su command to invoke superuser privileges is restricted to users who are members of a group named wheel.
Linux and Solaris have an id command that offers more detailed UIDs, GIDs, and group lists:
Few sysadmins and users know that you can change the user active group using the newgrp command. This is useful when a user
wants to create files owned by a group other than his default group.
$ newgrp project27
Solaris and other versions of Unix derived from AT&T SVR4 allow users to use newgrp to switch to a group that they are not
a member of if the group is equipped with a group password:
$ newgrp fiction
This looks like a backdoor and generally should be avoided.
But theoretically we can state that the password in the /etc/group file is interpreted exactly like the passwords
in the /etc/passwd file. However, most systems do not have a program to install or change the passwords in this file.
To set a group password, you must first assign it to a user with the passwd command, then use a text editor to copy the encrypted password
out of the /etc/passwd file into the /etc/group file. Alternatively, you can encode the password using
the proper program (if present) and edit the result into the /etc/group file in the appropriate place.
Group passwords are rarely used and can represent a security vulnerability, as an attacker can put a password on a critical group
as a way of creating a back door for future access.
Root can impersonate any user. for regular user in order to be able to impersonalized another user he/she need to know the other
user password. But this is against most corporation security policies to share password.
The alternative and more flexible way is to provide such a capability via sudo.
What to put into
In bash can read /etc/passwd file using the while loop and
IFS separator as follows (Understanding
-etc-passwd File Format - nixCraft )
# seven fields from /etc/passwd stored in $f1,f2...,$f7
while IFS=: read -r f1 f2 f3 f4 f5 f6 f7
echo "User $f1 use $f7 shell and stores files in $f6 directory."
done < /etc/passwd
But it is better to use Perl for this purpose.
passwd - Wikipedia
Prior to password shadowing, a Unix user's hashed password was stored in the second field of their record in the
file (within the seven-field format as outlined above).
Password shadowing first appeared in Unix systems with the development of
SunOS in the mid-1980s,
System V Release 3.2 in
1988 and BSD4.3 Reno in 1990. But,
vendors who had performed ports from earlier UNIX releases did not always include the new password shadowing features
in their releases, leaving users of those systems exposed to password file attacks.
System administrators may also arrange for the storage of passwords in distributed databases such as
LDAP, rather than in files on each
connected system. In the case of NIS, the shadow password mechanism is often still used on the NIS servers; in other
distributed mechanisms the problem of access to the various user authentication components is handled by the security
mechanisms of the underlying data repository.
In 1987 the author of the original Shadow Password Suite, Julie Haugh, experienced a computer break-in and
wrote the initial release of the Shadow Suite containing the
su commands. The original
release, written for the SCO Xenix operating system,
quickly got ported to other platforms. The Shadow Suite was ported to
Linux in 1992 one year after the original
announcement of the Linux project, and was included in many early distributions, and continues to be included in many
current Linux distributions.
In the past, it was necessary to have different commands to change passwords in different authentication schemes.
For example, the command to change a NIS password was yppasswd. This required users to be aware of the
different methods to change passwords for different systems, and also resulted in wasteful duplication of code in the
various programs that performed the same functions with different
back ends. In most
implementations, there is now a single passwd command, and the control of where the password is actually changed is
handled transparently to the user via
pluggable authentication modules (PAMs). For example, the type of hash used is dictated by the configuration of
pam_unix.so module. By default, the MD5
hash has been used, while current modules are also capable of stronger hashes such as
passwd - Wikipedia
Understanding -etc-passwd File Format - nixCraft
Unix security - Wikipedia
Two Party System
as Polyarchy :
Corruption of Regulators :
and Control Freaks : Toxic Managers :
Harvard Mafia :
: Surviving a Bad Performance
Review : Insufficient Retirement Funds as
Immanent Problem of Neoliberal Regime : PseudoScience :
Who Rules America :
: The Iron
Law of Oligarchy :
War and Peace
Finance : John
Kenneth Galbraith :Talleyrand :
Oscar Wilde :
Otto Von Bismarck :
George Carlin :
Propaganda : SE
quotes : Language Design and Programming Quotes :
Random IT-related quotes :
Somerset Maugham :
Marcus Aurelius :
Kurt Vonnegut :
Eric Hoffer :
Winston Churchill :
Napoleon Bonaparte :
Ambrose Bierce :
Bernard Shaw :
Mark Twain Quotes
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient
markets hypothesis :
Political Skeptic Bulletin, 2013 :
Unemployment Bulletin, 2010 :
Vol 23, No.10
(October, 2011) An observation about corporate security departments :
Slightly Skeptical Euromaydan Chronicles, June 2014 :
Greenspan legacy bulletin, 2008 :
Vol 25, No.10 (October, 2013) Cryptolocker Trojan
Vol 25, No.08 (August, 2013) Cloud providers
as intelligence collection hubs :
Financial Humor Bulletin, 2010 :
Inequality Bulletin, 2009 :
Financial Humor Bulletin, 2008 :
Bulletin, 2004 :
Financial Humor Bulletin, 2011 :
Energy Bulletin, 2010 :
Malware Protection Bulletin, 2010 : Vol 26,
No.1 (January, 2013) Object-Oriented Cult :
Political Skeptic Bulletin, 2011 :
Vol 23, No.11 (November, 2011) Softpanorama classification
of sysadmin horror stories : Vol 25, No.05
(May, 2013) Corporate bullshit as a communication method :
Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
Fifty glorious years (1950-2000):
the triumph of the US computer engineering :
Donald Knuth : TAoCP
and its Influence of Computer Science : Richard Stallman
: Linus Torvalds :
Larry Wall :
John K. Ousterhout :
CTSS : Multix OS Unix
History : Unix shell history :
VI editor :
History of pipes concept :
Solaris : MS DOS
: Programming Languages History :
PL/1 : Simula 67 :
History of GCC development :
Scripting Languages :
Perl history :
OS History : Mail :
DNS : SSH
: CPU Instruction Sets :
SPARC systems 1987-2006 :
Norton Commander :
Norton Utilities :
Norton Ghost :
Frontpage history :
Malware Defense History :
GNU Screen :
OSS early history
Principle : Parkinson
Law : 1984 :
The Mythical Man-Month :
How to Solve It by George Polya :
The Art of Computer Programming :
The Elements of Programming Style :
The Unix Hater’s Handbook :
The Jargon file :
The True Believer :
Programming Pearls :
The Good Soldier Svejk :
The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society :
of the IT Slackers Society : Computer Humor Collection
: BSD Logo Story :
The Cuckoo's Egg :
IT Slang : C++ Humor
: ARE YOU A BBS ADDICT? :
The Perl Purity Test :
Object oriented programmers of all nations
: Financial Humor :
Financial Humor Bulletin,
2008 : Financial
Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related
Humor : Programming Language Humor :
Goldman Sachs related humor :
Greenspan humor : C Humor :
Scripting Humor :
Real Programmers Humor :
Web Humor : GPL-related Humor
: OFM Humor :
Politically Incorrect Humor :
IDS Humor :
"Linux Sucks" Humor : Russian
Musical Humor : Best Russian Programmer
Humor : Microsoft plans to buy Catholic Church
: Richard Stallman Related Humor :
Admin Humor : Perl-related
Humor : Linus Torvalds Related
humor : PseudoScience Related Humor :
Networking Humor :
Shell Humor :
Financial Humor Bulletin,
2011 : Financial
Humor Bulletin, 2012 :
Financial Humor Bulletin,
2013 : Java Humor : Software
Engineering Humor : Sun Solaris Related Humor :
Education Humor : IBM
Humor : Assembler-related Humor :
VIM Humor : Computer
Viruses Humor : Bright tomorrow is rescheduled
to a day after tomorrow : Classic Computer
The Last but not Least
Copyright © 1996-2016 by Dr. Nikolai Bezroukov. www.softpanorama.org
was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP)
in the author free time and without any remuneration. This document is an industrial compilation designed and created exclusively
for educational use and is distributed under the Softpanorama Content License.
Original materials copyright belong
to respective owners. Quotes are made for educational purposes only
in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains
copyrighted material the use of which has not always been specifically
authorized by the copyright owner. We are making such material available
to advance understanding of computer science, IT technology, economic, scientific, and social
issues. We believe this constitutes a 'fair use' of any such
copyrighted material as provided by section 107 of the US Copyright Law according to which
such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free)
site written by people for whom English is not a native language. Grammar and spelling errors should
be expected. The site contain some broken links as it develops like a living tree...
The statements, views and opinions presented on this web page are those of the author (or
referenced source) and are
not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness
of the information provided or its fitness for any purpose.
Last modified: July 05, 2018