The /etc/passwd File

• Introduction
• Shadow file
• Groups and Group Identifiers (GIDs)
• The /etc/group file
• Group Passwords
• Impersonalization
• Consistency Checking
• Reading /etc/passwd file
• History

Introduction

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, 256 user you need something better that a text file. But most server contain less the a hundred accounts. For them passwd files is "perfect" as 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 via ssh or other protocol.  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

1. Username: It is used when user logs in. It should be between 1 and 32 characters in length.
2. 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 the password
3. 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. applications account occupy range 1K-10K. Typically user accounts start with 10K
4. Group ID (GID): The primary group ID (stored in /etc/group file). Often primary group IP is identical to UID (user private group scheme). for some time Red HAT pushed user private group and this was a default assignment in RHEL but starting with RHEL 6 this is no longer the case.
5. Gecos field, commentary that describes the person or account. Typically, this is a set of comma-separated values including the user's email (and sometimes other info such as full name, phone and location). In other words this is contact details and often they are needed ASAP if sysadmin has a problem with the account. So systematic handing of this field pays later huge dividends. In general email is enough, as all other attributes can be deducted from corporate directory.
6. 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 / (root)
7. 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 command line 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:

cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
adm:x:3:4:adm:/var/adm:/sbin/nologin
lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
mail:x:8:12:mail:/var/spool/mail:/sbin/nologin
news:x:9:13:news:/etc/news:
uucp:x:10:14:uucp:/var/spool/uucp:/sbin/nologin
operator:x:11:0:operator:/root:/sbin/nologin
games:x:12:100:games:/usr/games:/sbin/nologin
gopher:x:13:30:gopher:/var/gopher:/sbin/nologin
ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin
nobody:x:99:99:Nobody:/:/sbin/nologin
nscd:x:28:28:NSCD Daemon:/:/sbin/nologin
vcsa:x:69:69:virtual console memory owner:/dev:/sbin/nologin
ntp:x:38:38::/etc/ntp:/sbin/nologin
pcap:x:77:77::/var/arpwatch:/sbin/nologin
dbus:x:81:81:System message bus:/:/sbin/nologin
avahi:x:70:70:Avahi daemon:/:/sbin/nologin
rpc:x:32:32:Portmapper RPC user:/:/sbin/nologin
mailnull:x:47:47::/var/spool/mqueue:/sbin/nologin
smmsp:x:51:51::/var/spool/mqueue:/sbin/nologin
apache:x:48:48:Apache:/var/www:/sbin/nologin
sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/sbin/nologin
dovecot:x:97:97:dovecot:/usr/libexec/dovecot:/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
haldaemon:x:68:68:HAL daemon:/:/sbin/nologin
avahi-autoipd:x:100:156:avahi-autoipd:/var/lib/avahi-autoipd:/sbin/nologin
gdm:x:42:42::/var/gdm:/sbin/nologin
sabayon:x:86:86:Sabayon user:/home/sabayon:/sbin/nologin

There is generally nothing special about any Unix account name. All Unix privileges are determined by the UID plus the group ID (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 in Linux/Unix they mean the 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 third field of this file, 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.

NOTE: you can provide the ability to login to other  user account iether via SUDO, or via ssh passwordless login.

Shadow file

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 super user.

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 cleartext, e.g., Telnet^[4]), 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 login 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 '*', or '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, "$2a$" is Blowfish, "$2y$" is Blowfish (correct handling of 8-bit chars), "$5$" is SHA-256 and "$6$" is SHA-512,^[5] other Unix may have different values, like NetBSD. Key stretching is used to increase password cracking difficulty, using by default 1000 rounds of modified MD5,^[6] 64 rounds of Blowfish, 5000 rounds of SHA-256 or SHA-512.^[7] 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").^[8]
  • "!" – 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.^[9]
  • "*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.^[9]
  • "!!" – the password has never been set (RedHat)^[10]
• 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
• Reserved

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.

Groups and Group Identifiers (GIDs)

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). Historically GID values were also 16-bit integers, but many systems now use 32-bit or 64-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 single 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 called 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 group accordingly.

Consider, again, our /etc/passwd  example:

joeuser:x:9362:9362:Joe User:/home/joeuser:/bin/bash

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 primary group id (GID) uniformly on multiple servers. This simplifies the transfer of files between servers -- they are automatically owned by the same user.

Groups provide a handy mechanism for providing a subset of users access to some subset 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 genome FASTQ/FASTA 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 memory.

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 problem even if the person who discovered the problem does not have access to spreadsheet or database with the servers assignment for sysadmin group. In a large corporation 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 operations 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 particular software or sensitive files.

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 unnecessary complicates things, but should be enabled for all server facing Internet and servers with privileged information such as credit cards data.

The /etc/group file

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.   

[0]bezroun@lustwz54: $ cat /etc/group
root:x:0:root
bin:x:1:root,bin,daemon
daemon:x:2:root,bin,daemon
sys:x:3:root,bin,adm
adm:x:4:root,adm,daemon
tty:x:5:
disk:x:6:root
lp:x:7:daemon,lp
mem:x:8:
kmem:x:9:
wheel:x:10:root,bezroun
mail:x:12:mail
news:x:13:news
uucp:x:14:uucp
man:x:15:
games:x:20:
gopher:x:30:
dip:x:40:
ftp:x:50:
lock:x:54:
nobody:x:99:
users:x:100:
utmp:x:22:
utempter:x:35:
nscd:x:28:
vcsa:x:69:
ntp:x:38:
pcap:x:77:
slocate:x:21:
dbus:x:81:
audio:x:63:gdm
avahi:x:70:
rpc:x:32:
mailnull:x:47:
smmsp:x:51:
apache:x:48:
sshd:x:74:
dovecot:x:97:
oprofile:x:16:
screen:x:84:
rpcuser:x:29:
nfsnobody:x:65534:
xfs:x:43:
stapdev:x:101:
stapusr:x:102:
stap-server:x:155:
haldaemon:x:68:
avahi-autoipd:x:156:
gdm:x:42:
sabayon:x:86:

One important group is  the Wheel 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:

Group Passwords

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.

$ id
uid=10001(furrycat) gid=100(users)
$ newgrp project27
$ id
uid=1001(furrycat) gid=866(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
password: rates34

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.

Impersonalization

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.

Another alternative is using passwordless SSH login.

Consistency Checking

Linux distributions usually provide a pwck utility. This small utility will check the consistency of both files and state any specific issues. By specifying the -r it may run in read-only mode. It also can sort /etc/passwd, /etc/shadow and /etc/group files.

The pwck command verifies the integrity of the users and authentication information. It checks that all entries in /etc/passwd and /etc/shadow have the proper format and contain valid data. The user is prompted to delete entries that are improperly formatted or which have other uncorrectable errors.

Checks are made to verify that each entry has:

• the correct number of fields
• a unique and valid user name
• a valid user and group identifier
• a valid primary group
• a valid home directory
• a valid login shell
• shadow checks are enabled when a second file parameter is specified or when /etc/shadow exists on the system.

These checks are the following:

• every passwd entry has a matching shadow entry, and every shadow entry has a matching passwd entry
• passwords are specified in the shadowed file
• shadow entries have the correct number of fields
• shadow entries are unique in shadow
• the last password changes are not in the future

The checks for correct number of fields and unique user name are fatal. If the entry has the wrong number of fields, the user will be prompted to delete the entire line. If the user does not answer affirmatively, all further checks are bypassed. An entry with a duplicated user name is prompted for deletion, but the remaining checks will still be made. All other errors are warning and the user is encouraged to run the usermod command to correct the error.

The commands which operate on the /etc/passwd file are not able to alter corrupted or duplicated entries. pwck should be used in those circumstances to remove the offending entry.

The options which apply to the pwck command are:

• -q Report errors only. The warnings which do not require any action from the user won't be displayed.
• -r Execute the pwck command in read-only mode.
• -s Sort entries in /etc/passwd and /etc/shadow by UID.

By default, pwck operates on the files /etc/passwd and /etc/shadow. The user may select alternate files with the passwd and shadow parameters.

The number of records in /etc/passwd and /etc/shadow files should be identical and order of records should be identical too. To ensure this you can sort both /etc/passwd and /etc/shadow by UID using  pwck -s and grpck -s commands respectivly.

You can also use Unix sort command.

sort -t ':' -n -k3,3 /etc/passwd 

where:

• Option -t defines the separator, which is colon in /etc/passwd file.
• Option -n is necessary so that the sort key is interpreted as a number,  not  as a string.
• Option -k defines the sorting field.

The chances are that your password database is in something of a state of disrepair. In the past people used to maintain the password file (/etc/passwd, /etc/shadow and /etc/group) by hand. That's what the vipw and vigr commands were for: locking the files while they were being edited to make sure that sysadmins didn't overwrite each other's work. And because they were hand edited, people tended to keep the files ordered by increasing user or group id.

These days, though, it's more likely that you'll be using a tool like useradd to put entries in these files, and these tools invariably plonk new entries at the end of the file. Adding and removing packages (with tools like rpm) can also create and delete users and groups, so after a few years of system upgrades you can finish up with files that are anything but sorted. That can be a real problem if you want to make sure two password files on different systems contain the same entries, for example.

Sorting the password and group files is actually really easy, because the Unix sort command is so flexible. The following command will sort the lines of the password file into ascending order by user id:

$ sort -g -t : -k 3 /etc/passwd

and this will do the group file:

$ sort -g -t : -k 3 /etc/group

those with sharp eyes will notice that the commands are the same: the user id and group id are the third fields in both files, and they both use : as a field separator, so the arguments to sort are the same.

Ok, so that sorts the file, but the results just get printed to the terminal. How do we sort the password file in place? Well, you could play around with redirecting the output into a temporary file and then renaming it, but we can return to our old friends vipw and vigr for a slightly tidier solution. Run vipw to load the password file into vi, then type !G to filter the whole of the file through a command. You'll be prompted to enter the command at the bottom of the screen (in vim the prompt looks like :.,$!); enter sort -g -t : -k 3 and press return. The password entries should now be sorted into ascending order. If all seems well save the file and quit the editor. You can then run vigr to do the same transformation on your group file.

What's that? Oh, vipw and vigr are prompting you to edit the shadow password and shadow group files, and they're not in order either? Ah, well that a more tricky problem - neither of these files contains the user id, so we really need to sort them so that the user names (or group names) are in the same order as the names in the password (or group) file, and that's a bit more than we can get sort to do.

There is another way to do all this though: the pwck and grpck commands have a little-known -s option that will sort their respective databases. So another way to get things sorted out would be:

$ pwck -s
$ grpck -s

which is very brief, but we don't find out how to use sort that way...

Reading /etc/passwd file

In bash can read /etc/passwd file using the while loop and IFS separator as follows (Understanding -etc-passwd File Format - nixCraft )

#!/bin/bash
# seven fields from /etc/passwd stored in $f1,f2...,$f7
# 
while IFS=: read -r f1 f2 f3 f4 f5 f6 f7
do 
 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.

History

passwd - Wikipedia

Prior to password shadowing, a Unix user's hashed password was stored in the second field of their record in the /etc/passwd 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,^[11] 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 NIS and 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 login, passwd and 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 the pam_unix.so module. By default, the MD5 hash has been used, while current modules are also capable of stronger hashes such as blowfish, SHA256 and SHA512.

 

NEWS CONTENTS

• 20180807 : May I sort the -etc-group and -etc-passwd files ( Aug 07, 2018 , unix.stackexchange.com )
• 20180807 : Consistency checking of /etc/passwd and /etc/shadow ( Aug 07, 2018 , linux-audit.com )
• 20180807 : passwd - Copying Linux users and passwords to a new server ( Aug 07, 2018 , serverfault.com )

Old News ;-)

[Aug 07, 2018] May I sort the -etc-group and -etc-passwd files

Aug 07, 2018 | unix.stackexchange.com

Ned64 ,Feb 18 at 13:52

My /etc/group has grown by adding new users as well as installing programs that have added their own user and/or group. The same is true for /etc/passwd . Editing has now become a little cumbersome due to the lack of structure.

May I sort these files (e.g. by numerical id or alphabetical by name) without negative effect on the system and/or package managers?

I would guess that is does not matter but just to be sure I would like to get a 2nd opinion. Maybe root needs to be the 1st line or within the first 1k lines or something?

The same goes for /etc/*shadow .

Kevin ,Feb 19 at 23:50

"Editing has now become a little cumbersome due to the lack of structure" Why are you editing those files by hand? – Kevin Feb 19 at 23:50

Barmar ,Feb 21 at 20:51

How does sorting the file help with editing? Is it because you want to group related accounts together, and then do similar changes in a range of rows? But will related account be adjacent if you sort by uid or name? – Barmar Feb 21 at 20:51

Ned64 ,Mar 13 at 23:15

@Barmar It has helped mainly because user accounts are grouped by ranges and separate from system accounts (when sorting by UID). Therefore it is easier e.g. to spot the correct line to examine or change when editing with vi . – Ned64 Mar 13 at 23:15

ErikF ,Feb 18 at 14:12

You should be OK doing this : in fact, according to the article and reading the documentation, you can sort /etc/passwd and /etc/group by UID/GID with pwck -s and grpck -s , respectively.

hvd ,Feb 18 at 22:59

@Menasheh This site's colours don't make them stand out as much as on other sites, but "OK doing this" in this answer is a hyperlink. – hvd Feb 18 at 22:59

mickeyf ,Feb 19 at 14:05

OK, fine, but... In general, are there valid reasons to manually edit /etc/passwd and similar files? Isn't it considered better to access these via the tools that are designed to create and modify them? – mickeyf Feb 19 at 14:05

ErikF ,Feb 20 at 21:21

@mickeyf I've seen people manually edit /etc/passwd when they're making batch changes, like changing the GECOS field for all users due to moving/restructuring (global room or phone number changes, etc.) It's not common anymore, but there are specific reasons that crop up from time to time. – ErikF Feb 20 at 21:21

hvd ,Feb 18 at 17:28

Although ErikF is correct that this should generally be okay, I do want to point out one potential issue:

You're allowed to map different usernames to the same UID. If you make use of this, tools that map a UID back to a username will generally pick the first username they find for that UID in /etc/passwd . Sorting may cause a different username to appear first. For display purposes (e.g. ls -l output), either username should work, but it's possible that you've configured some program to accept requests from username A, where it will deny those requests if it sees them coming from username B, even if A and B are the same user.

Rui F Ribeiro ,Feb 19 at 17:53

Having root at first line has been a long time de facto "standard" and is very convenient if you ever have to fix their shell or delete the password, when dealing with problems or recovering systems.

Likewise I prefer to have daemons/utils users in the middle and standard users at the end of both passwd and shadow .

hvd answer is also very good about disturbing the users order, especially in systems with many users maintained by hand.

If you somewhat manage to sort the files, for instance, only for standard users, it would be more sensible than changing the order of all users, imo.

Barmar ,Feb 21 at 20:13

If you sort numerically by UID, you should get your preferred order. Root is always 0 , and daemons conventionally have UIDs under 100. – Barmar Feb 21 at 20:13

Rui F Ribeiro ,Feb 21 at 20:16

@Barmar If sorting by UID and not by name, indeed, thanks for remembering. – Rui F Ribeiro Feb 21 at 20:16

[Aug 07, 2018] Consistency checking of /etc/passwd and /etc/shadow

Aug 07, 2018 | linux-audit.com

Linux distributions usually provide a pwck utility. This small utility will check the consistency of both files and state any specific issues. By specifying the -r it may run in read-only mode.

Example when running pwck on /etc/passwd and /etc/shadow file

[Aug 07, 2018] passwd - Copying Linux users and passwords to a new server

Aug 07, 2018 | serverfault.com

I am migrating over a server to new hardware. A part of the system will be rebuild. What files and directories are needed to copy so that usernames, passwords, groups, file ownership and file permissions stay intact?

Ubuntu 12.04 LTS. linux passwd share | improve this question asked Mar 20 '14 at 7:47

Mikko Ohtamaa, Mar 20 '14 at 7:54

/etc/passwd - user account information less the encrypted passwords 
/etc/shadow - contains encrypted passwords 
/etc/group - user group information 
/etc/gshadow - - group encrypted passwords

Be sure to ensure that the permissions on the files are correct too share | improve this answer edited Mar 20 '14 at 9:48 answered

Iain 102k 13 154 250

• 5 +1 from me. I wondered about /home as well; generally, ssh keys live in the home directories, so ~/.ssh at least can be considered part of the authentication infrastructure. – MadHatter Mar 20 '14 at 8:33
• 2 @MadHatter: In truth I kind of assumed that the OP would know that they needed to copy the user home directories but I guess you never know here on SF :) – Iain Mar 20 '14 at 8:37
• 1 Don't worry, the author knows. – Mikko Ohtamaa Mar 20 '14 at 8:53
• 2 Although the above will work, you should realy copy over gshadow too. – symcbean Mar 20 '14 at 9:45
• 6 An important point: this assumes a server with file-based authentication only. To migrate a server that uses e.g. LDAP or NIS these files will not be enough, especially if the authentication server is on the same system. Other subsystems (e.g. Samba, SQL) may also have their own authentication databases. – thkala Mar 20 '14 at 16:55

| show 4 more comments up vote 13 down vote

I did this with Gentoo Linux already and copied:

• /etc/passwd
• /etc/shadow
• /etc/group
• /etc/gshadow

that's it.

If the files on the other machine have different owner IDs, you might change them to the ones on /etc/group and /etc/passwd and then you have the effective permissions restored. share | improve this answer edited Mar 20 '14 at 11:52 answered Mar 20 '14 at 7:53

vanthome 560 3 10

Be careful that you don't delete or renumber system accounts when copying over the files mentioned in the other answers. System services don't usually have fixed user ids, and if you've installed the packages in a different order to the original machine (which is very likely if it was long-lived), then they'll end up in a different order. I tend to copy those files to somewhere like /root/saved-from-old-system and hand-edit them in order to just copy the non-system accounts. (There's probably a tool for this, but I don't tend to copy systems like this often enough to warrant investigating one.)Mar 26 '14 at 5:36

Recommended Links

Softpanorama Recommended

Top articles

Sites

passwd - Wikipedia

Understanding -etc-passwd File Format - nixCraft

Unix security - Wikipedia

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : 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

Bulletin:

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 (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems 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

History:

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 : C : 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

Classic books:

The Peter 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 : Ten Commandments 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 Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

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 Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: July 28, 2019