1
- <!-- $Header: /cvsroot/pgsql/doc/src/sgml/client-auth.sgml,v 1.1 2000/06/18 21:24 :51 petere Exp $ -->
1
+ <!-- $Header: /cvsroot/pgsql/doc/src/sgml/client-auth.sgml,v 1.2 2000/07/04 16:31 :51 petere Exp $ -->
2
2
3
3
<chapter id="client-authentication">
4
4
<title>Client Authentication</title>
@@ -202,15 +202,15 @@ host all 192.168.2.0 255.255.255.0 ident othermap
202
202
<term>password</term>
203
203
<listitem>
204
204
<para>
205
- The client is required to supply a password for the connection
205
+ The client is required to supply a password with the connection
206
206
attempt which is required to match the password that was set up
207
- for the user. (These passwords are separate from any operating
208
- sytem password.)
207
+ for the user.
209
208
</para>
210
209
<para>
211
- An optional password file may be specified after the
212
- <literal>password</literal> keyword to obtain the password from
213
- that file rather than the pg_shadow system catalog.
210
+ An optional file name may be specified after the
211
+ <literal>password</literal> keyword. This file is expected to
212
+ contain a list of users that this record pertains to, and
213
+ optionally alternative passwords.
214
214
</para>
215
215
<para>
216
216
The password is sent over the wire in clear text. For better
@@ -225,11 +225,11 @@ host all 192.168.2.0 255.255.255.0 ident othermap
225
225
<para>
226
226
Like the <literal>password</literal> method, but the password
227
227
is sent over the wire encrypted using a simple
228
- challenge-response protocol. Note that this is still not
228
+ challenge-response protocol. This is still not
229
229
cryptographically secure but it protects against incidental
230
- wire-sniffing. Interestingly enough, the
231
- <literal>crypt</literal> does not support secondary password
232
- files .
230
+ wire-sniffing. The name of a file may follow the
231
+ <literal>crypt</literal> keyword that contains a list of users
232
+ that this record pertains to .
233
233
</para>
234
234
</listitem>
235
235
</varlistentry>
@@ -276,24 +276,36 @@ host all 192.168.2.0 255.255.255.0 ident othermap
276
276
<sect2>
277
277
<title>Password authentication</title>
278
278
<para>
279
- Ordinarily, the password for each database user is stored in the
280
- pg_shadow system catalog table. Passwords can be managed with the
281
- query language commands <command>CREATE USER</command> and
282
- <command>ALTER USER</command>, e.g., <userinput>CREATE USER foo
283
- WITH PASSWORD 'secret';</userinput>. By default, that is, if no
284
- password has explicitly been set up, the stored password is
285
- <quote>NULL</quote> and password authentication will always fail
286
- for that user.
279
+ <productname>Postgres</> database passwords are separate from any
280
+ operating system user passwords. Ordinarily, the password for each
281
+ database user is stored in the pg_shadow system catalog table.
282
+ Passwords can be managed with the query language commands
283
+ <command>CREATE USER</command> and <command>ALTER USER</command>,
284
+ e.g., <userinput>CREATE USER foo WITH PASSWORD
285
+ 'secret';</userinput>. By default, that is, if no password has
286
+ explicitly been set up, the stored password is <quote>NULL</quote>
287
+ and password authentication will always fail for that user.
287
288
</para>
288
289
289
290
<para>
290
- Secondary password files can be used if a given set of passwords
291
- should only apply to a particular database or set thereof.
292
- Secondary password files have a format similar to the standard
293
- Unix password file <filename>/etc/passwd</filename>, that is,
294
- <synopsis>
291
+ To restrict the set of users that are allowed to connect to
292
+ certain databases, list the set of users in a separate file (one
293
+ user name per line) in the same directory that
294
+ <filename>pg_hba.conf</> is in, and mention the (base) name of the
295
+ file after the <literal>password</> or <literal>crypt</> keyword,
296
+ respectively, in <filename>pg_hba.conf</>. If you do not use this
297
+ feature, then any user that is known to the database system can
298
+ connect (as long as he passes password authentication, of course).
299
+ </para>
300
+
301
+ <para>
302
+ These files can also be used a apply a different set of passwords
303
+ to a particular database or set thereof. In that case, the files
304
+ have a format similar to the standard Unix password file
305
+ <filename>/etc/passwd</filename>, that is,
306
+ <synopsis>
295
307
<replaceable>username</replaceable>:<replaceable>password</replaceable>
296
- </synopsis>
308
+ </synopsis>
297
309
Any extra colon separated fields following the password are
298
310
ignored. The password is expected to be encrypted using the
299
311
system's <function>crypt()</function> function. The utility
@@ -303,20 +315,29 @@ host all 192.168.2.0 255.255.255.0 ident othermap
303
315
</para>
304
316
305
317
<para>
306
- Secondary password files can also be used to restrict certain
307
- users from connecting to certain databases at all. This is
308
- currently not possible to achieve using the normal password
309
- mechanism (because users and passwords are global across all
310
- databases). If a user is not listed in the applicable password
311
- file the connection will be refused .
318
+ Lines with and without passwords can be mixed in secondary
319
+ password files. Lines without password indicate use the main
320
+ password in <literal>pg_shadow</> that is managed by
321
+ <command>CREATE USER</> and <command>ALTER USER</>. Lines with
322
+ passwords will cause that password to be used. A password entry of
323
+ <quote>+</quote> also means using the pg_shadow password .
312
324
</para>
313
325
314
326
<para>
315
- Note that using secondary password files means that one can no
316
- longer use <command>ALTER USER</command> to change one's password.
317
- It will still appear to work but the password one is actually
318
- changing is not the password that the system will end up using .
327
+ Alternative passwords cannot be used when using the
328
+ <literal>crypt</> method. The file will still be evaluated as
329
+ usual but the password field will simply be ignored and the
330
+ <literal>pg_shadow</> password will be used .
319
331
</para>
332
+
333
+ <para>
334
+ Note that using alternative passwords like this means that one can
335
+ no longer use <command>ALTER USER</command> to change one's
336
+ password. It will still appear to work but the password one is
337
+ actually changing is not the password that the system will end up
338
+ using.
339
+ </para>
340
+
320
341
</sect2>
321
342
322
343
<sect2>
@@ -361,14 +382,15 @@ integrated here. -->
361
382
The <quote>Identification Protocol</quote> is described in
362
383
<citetitle>RFC 1413</citetitle>. Virtually every Unix-like
363
384
operating systems ships with an ident server that listens on TCP
364
- port 113 by default. The basic functionality of the ident server
385
+ port 113 by default. The basic functionality of an ident server
365
386
is to answer questions like <quote>What user initiated the
366
387
connection that goes out of your port <replaceable>X</replaceable>
367
388
and connects to my port <replaceable>Y</replaceable>?</quote>.
368
- Since both <replaceable>X</replaceable> and
369
- <replaceable>Y</replaceable> are known,
370
- <productname>Postgres</productname> could theoretically determine
371
- the operating system user for any given connection this way.
389
+ Since <productname>Postgres</> knows both <replaceable>X</> and
390
+ <replaceable>Y</> when a physical connection is established, it
391
+ can interrogate the ident server on the host of the connecting
392
+ client and could theoretically determine the operating system user
393
+ for any given connection this way.
372
394
</para>
373
395
374
396
<para>
0 commit comments