summary refs log tree commit diff
path: root/pwd
diff options
context:
space:
mode:
authorZack Weinberg <zackw@panix.com>2018-06-29 16:53:37 +0200
committerFlorian Weimer <fweimer@redhat.com>2018-06-29 16:53:37 +0200
commit841785bad14dfad81a0af94900310141c59f26a4 (patch)
tree9fba8a7c16596dcb9652576f9322c810eb0cf682 /pwd
parent6ab902e4decd89c1a9206497d14ddba7680bfc37 (diff)
downloadglibc-841785bad14dfad81a0af94900310141c59f26a4.tar.gz
glibc-841785bad14dfad81a0af94900310141c59f26a4.tar.xz
glibc-841785bad14dfad81a0af94900310141c59f26a4.zip
manual: Revise crypt.texi.
This is a major rewrite of the description of 'crypt', 'getentropy',
and 'getrandom'.

A few highlights of the content changes:

 - Throughout the manual, public headers, and user-visible messages,
   I replaced the term "password" with "passphrase", the term
   "password database" with "user database", and the term
   "encrypt(ion)" with "(one-way) hashing" whenever it was applied to
   passphrases.  I didn't bother making this change in internal code
   or tests.  The use of the term "password" in ruserpass.c survives,
   because that refers to a keyword in netrc files, but it is adjusted
   to make this clearer.

   There is a note in crypt.texi explaining that they were
   traditionally called passwords but single words are not good enough
   anymore, and a note in users.texi explaining that actual passphrase
   hashes are found in a "shadow" database nowadays.

 - There is a new short introduction to the "Cryptographic Functions"
   section, explaining how we do not intend to be a general-purpose
   cryptography library, and cautioning that there _are_, or have
   been, legal restrictions on the use of cryptography in many
   countries, without getting into any kind of detail that we can't
   promise to keep up to date.

 - I added more detail about what a "one-way function" is, and why
   they are used to obscure passphrases for storage.  I removed the
   paragraph saying that systems not connected to a network need no
   user authentication, because that's a pretty rare situation
   nowadays.  (It still says "sometimes it is necessary" to
   authenticate the user, though.)

 - I added documentation for all of the hash functions that glibc
   actually supports, but not for the additional hash functions
   supported by libxcrypt.  If we're going to keep this manual section
   around after the transition is more advanced, it would probably
   make sense to add them then.

 - There is much more detailed discussion of how to generate a salt,
   and the failure behavior for crypt is documented.  (Returning an
   invalid hash on failure is what libxcrypt does; Solar Designer's
   notes say that this was done "for compatibility with old programs
   that assume crypt can never fail".)

 - As far as I can tell, the header 'crypt.h' is entirely a GNU
   invention, and never existed on any other Unix lineage.  The
   function 'crypt', however, was in Issue 1 of the SVID and is now
   in the XSI component of POSIX.  I tried to make all of the
   @standards annotations consistent with this, but I'm not sure I got
   them perfectly right.

 - The genpass.c example has been improved to use getentropy instead
   of the current time to generate the salt, and to use a SHA-256 hash
   instead of MD5. It uses more random bytes than is strictly
   necessary because I didn't want to complicate the code with proper
   base64 encoding.

 - The testpass.c example has three hardwired hashes now, to
   demonstrate that different one-way functions produce different
   hashes for the same input.  It also demonstrates how DES hashing
   only pays attention to the first eight characters of the input.

 - There is new text explaining in more detail how a CSPRNG differs
   from a regular random number generator, and how
   getentropy/getrandom are not exactly a CSPRNG.  I tried not to make
   specific falsifiable claims here.  I also tried to make the
   blocking/cancellation/error behavior of both getentropy and
   getrandom clearer.
Diffstat (limited to 'pwd')
-rw-r--r--pwd/pwd.h29
1 files changed, 15 insertions, 14 deletions
diff --git a/pwd/pwd.h b/pwd/pwd.h
index 25c6b97551..e6d20cd78b 100644
--- a/pwd/pwd.h
+++ b/pwd/pwd.h
@@ -45,11 +45,12 @@ typedef __uid_t uid_t;
 # endif
 #endif
 
-/* The passwd structure.  */
+/* A record in the user database.  */
 struct passwd
 {
   char *pw_name;		/* Username.  */
-  char *pw_passwd;		/* Password.  */
+  char *pw_passwd;		/* Hashed passphrase, if shadow database
+                                   not in use (see shadow.h).  */
   __uid_t pw_uid;		/* User ID.  */
   __gid_t pw_gid;		/* Group ID.  */
   char *pw_gecos;		/* Real name.  */
@@ -64,19 +65,19 @@ struct passwd
 
 
 #if defined __USE_MISC || defined __USE_XOPEN_EXTENDED
-/* Rewind the password-file stream.
+/* Rewind the user database stream.
 
    This function is a possible cancellation point and therefore not
    marked with __THROW.  */
 extern void setpwent (void);
 
-/* Close the password-file stream.
+/* Close the user database stream.
 
    This function is a possible cancellation point and therefore not
    marked with __THROW.  */
 extern void endpwent (void);
 
-/* Read an entry from the password-file stream, opening it if necessary.
+/* Read an entry from the user database stream, opening it if necessary.
 
    This function is a possible cancellation point and therefore not
    marked with __THROW.  */
@@ -84,7 +85,7 @@ extern struct passwd *getpwent (void);
 #endif
 
 #ifdef	__USE_MISC
-/* Read an entry from STREAM.
+/* Read a user database entry from STREAM.
 
    This function is not part of POSIX and therefore no official
    cancellation point.  But due to similarity with an POSIX interface
@@ -92,7 +93,7 @@ extern struct passwd *getpwent (void);
    therefore not marked with __THROW.  */
 extern struct passwd *fgetpwent (FILE *__stream) __nonnull ((1));
 
-/* Write the given entry onto the given stream.
+/* Write a given user database entry onto the given stream.
 
    This function is not part of POSIX and therefore no official
    cancellation point.  But due to similarity with an POSIX interface
@@ -102,13 +103,13 @@ extern int putpwent (const struct passwd *__restrict __p,
 		     FILE *__restrict __f);
 #endif
 
-/* Search for an entry with a matching user ID.
+/* Retrieve the user database entry for the given user ID.
 
    This function is a possible cancellation point and therefore not
    marked with __THROW.  */
 extern struct passwd *getpwuid (__uid_t __uid);
 
-/* Search for an entry with a matching username.
+/* Retrieve the user database entry for the given username.
 
    This function is a possible cancellation point and therefore not
    marked with __THROW.  */
@@ -155,8 +156,8 @@ extern int getpwnam_r (const char *__restrict __name,
 
 
 # ifdef	__USE_MISC
-/* Read an entry from STREAM.  This function is not standardized and
-   probably never will.
+/* Read a user database entry from STREAM.  This function is not
+   standardized and probably never will.
 
    This function is not part of POSIX and therefore no official
    cancellation point.  But due to similarity with an POSIX interface
@@ -172,9 +173,9 @@ extern int fgetpwent_r (FILE *__restrict __stream,
 #endif	/* POSIX or reentrant */
 
 #ifdef __USE_GNU
-/* Re-construct the password-file line for the given uid
-   in the given buffer.  This knows the format that the caller
-   will expect, but this need not be the format of the password file.
+/* Write a traditional /etc/passwd line, based on the user database
+   entry for the given UID, to BUFFER; space for BUFFER must be
+   allocated by the caller.
 
    This function is not part of POSIX and therefore no official
    cancellation point.  But due to similarity with an POSIX interface