If the second field of the /etc/shadow
file is set to !!
, does it mean that the account is disabled? Or does it mean that the account is active with no password assigned?
Linux – Second field in /etc/shadow
linuxpasswordshadow
Related Solutions
As far as I know, all unix variants have an /etc/passwd
file with the traditional layout, for the sake of applications that read the file directly. Each line in the file contains colon-separated records which correspond to struct passwd
fields:
- user name (login)
- encrypted password (if present)
- user id (number, in decimal)
- principal group id (number, in decimal)
- Gecos field. This field is not used by system programs except for display purposes. It is normally a comma-separated list of fields, the first three being full name, office number and telephone number.
- home directory
- login shell
One thing that varies between systems is how much liberty you can take with the syntax. For example, GNU libc (i.e. Linux) ignores lines that begin with #
: they are comments. GNU libc also ignores whitespace at the beginning of a line, so they can be indented. An invalid line might cause programs to stop processing the file or to skip to the next line.
Most modern systems no longer store an encrypted password in the second field. The content of that field is not a reliable indication of whether the user has a password set (and even if you found that out, this is not a reliable indication of whether the user can log in, because there are many other authentication methods such as SSH keys, one-time passwords, biometrics, smartcards, …).
When passwords aren't in /etc/passwd
, where they are is system-dependent. The Rosetta Stone for Unix mentions many unix variants.
- Solaris uses
/etc/shadow
, and this has been copied by others including Linux. Linux and Solaris shadow files have the same format; I don't know if the other systems that have a file called/etc/shadow
use the same format. - BSD systems have
/etc/master.passwd
, and additionally have database files for faster access, updated bypwd_mkdb
.
Remember that /etc/passwd
hasn't been guaranteed to contain the full list of users for a couple of decades: users can come from other databases such as NIS (YP) or LDAP. As a system administrator, avoid edit the /etc/passwd
file directly; use vipw
instead, if your system provides it (and if it doesn't, consult your manuals to see what method is recommended to modify the user database).
What I wrote above goes for groups, too. The fields in /etc/group
are struct group
members: group name, password (largely unused), numerical group id, and a comma-separated list of user names (the users who have this group as a secondary group). Linux has a /etc/gshadow
file, but this is rarely used, as group authentication is not widely practiced.
NP
in the password field of /etc/shadow
indicates that that the account cannot be logged into with a password but can be logged into with other authentication methods, such as su
down from root or cron jobs. NP
means that password authentication will always fail, but other login methods may succeed. You can set an account in this state with passwd -N
. This differs from *LK*
(reported as LK
by passwd -s
), which disables all logins to the account regardless of the authentication method.
Confusingly, when passwd -s
sees NP
in /etc/shadow
, it reports NL
, whereas NP
in the passwd -l
report indicates that the account is open to all winds: users will be authenticated without even getting a password prompt (this is indicated by an empty password field in /etc/shadow
).
UP
is a documented code in the passwd -s
output on Solaris 11 (not on Solaris 11 Express). It means that “this account has not yet been activated by the administrator and cannot be used.” If I understand the documentation correctly, its effect is similar to NP
; the intent is that the system administrator will run passwd
later to set a password (i.e. it's the first stage in the process where the admin creates the account for a future user, then later has the user type a password when they first come on-site). The documentation doesn't indicate whether passwd -s
reports UP
when it finds that in /etc/shadow
; while this is plausible, the confusion around NP
invites caution.
Usually, anything in the password field of /etc/shadow
(or other password database) that isn't an empty string is treated as a hashed password, and leads to a denied authentication if it doesn't match any of the valid hashed password formats. This is the case with normal password authentication on OpenSolaris, I can't speak for other versions but would be somewhat surprised if this wasn't the case.
Note that if there are several entries for the same user, I think only the first one is taken into account. (At least that's the case under Linux, and I have no reason to believe that Solaris would be different in this respect.)
Best Answer
If the password field contains some string that is not a valid result of crypt(3), for instance
!
or*
, the user will not be able to use a unix password to log in (but the user may log in the system by other means e.g .key based login).crypt()
is the password encryption function. It is based on the Data Encryption Standard algorithm with variations intended (among other things) to discourage use of hardware implementations of a key search key is a user's typed password. Salt is a two-character string chosen from the set[a–zA–Z0–9./]
. Following are some status exception values.Sources:
man shadow
andman 3 crypt
, Shadow File from Wikipedia and Red Hat.