1READERS.CONF(5) InterNetNews Documentation READERS.CONF(5)
2
6 readers.conf - Access control and configuration for nnrpd
7
9 readers.conf in pathetc specifies access control for nnrpd(8). It con‐
10 trols who is allowed to connect as a news reader and what they're
11 allowed to do after they connect. nnrpd reads this file when it starts
12 up. This generally means that any changes take effect immediately on
13 all subsequent connections, but nnrpd may have to be restarted if you
14 use the -D option. (The location pathetc/readers.conf is only the
15 default; the same format applies to any file specified with "nnrpd
16 -c".)
17 There are two types of entries in readers.conf: parameter/value pairs
19 and configuration groups. Blank lines and anything after a number sign
20 ("#") are ignored, unless the character "#" is escaped with "\". The
21 maximum number of characters on each line is 8,191.
22 Parameter/value pairs consist of a keyword immediately followed by a
24 colon, at least one whitespace character, and a value. The case of the
25 parameter is significant (parameter should generally be in all lower‐
26 case), and a parameter may contain any characters except colon, "#",
27 and whitespace. An example:
28 hosts: *.example.com
30 Values that contain whitespace should be quoted with double quotes, as
32 in:
33 hosts: "*.example.com, *.example.net"
35 If the parameter does not contain whitespace, such as:
37 hosts: *.example.com,*.example.net
39 it's not necessary to quote it, although you may wish to anyway for
41 clarity.
42 There is no way to continue a line on the next line, and therefore no
44 way to have a single parameter with a value longer than about 8,180
45 characters.
46 Many parameters take a boolean value. For all such parameters, the
48 value may be specified as "true", "yes", or "on" to turn it on and may
49 be any of "false", "no", or "off" to turn it off. The case of these
50 values is not significant.
51 There are two basic types of configuration groups, auth and access.
53 The auth group provides mechanisms to establish the identity of the
54 user, who they are. The access group determines, given the user's
55 identity, what that user is permitted to do. Writing a readers.conf
56 file for your setup is a two-step process: first assigning an identity
57 to each incoming connection using auth groups, and then giving each
58 identity appropriate privileges with access group. We recommend not
59 intermingling auth groups and access groups in the config file; it is
60 often more sensible (in the absence of the key parameter) to put all of
61 the auth groups first, and all of the access groups below.
62 A user identity, as established by an auth group, looks like an e-mail
64 address; in other words, it's in the form "<username>@<domain>" (or
65 sometimes just "<username>" if no domain is specified.
66 If nnrpdauthsender is set in inn.conf, the user identity is also put
68 into the Sender: header of posts made by that user. See the documenta‐
69 tion of that option in inn.conf(5) for more details.
70 An auth group definition looks like:
72 auth <name> {
74 hosts: <host-wildmat>
75 auth: <auth-program>
76 res: <res-program>
77 default: <defuser>
78 default-domain: <defdomain>
79 # ...possibly other settings
80 }
81 The <name> is used as a label for the group and is only for documenta‐
83 tion purposes. (If your syslog configuration records the "news.debug"
84 facility, the <name> will appear in the debugging output of nnrpd.
85 Examining that output can be very helpful in understanding why your
86 configuration doesn't do what you expect it to.)
87 A given auth group applies only to hosts whose name or IP address
89 matches the wildmat expression given with the hosts: parameter
90 (comma-separated wildmat expressions allowed, but "@" is not sup‐
91 ported). Rather than wildmat expressions, you may also use CIDR nota‐
92 tion to match any IP address in a netblock; for example,
93 "10.10.10.0/24" will match any IP address between 10.10.10.0 and
94 10.10.10.255 inclusive.
95 If compiled against the SSL libraries, an auth group with the
97 require_ssl: parameter set to true only applies if the incoming connec‐
98 tion is using SSL.
99 For any connection from a host that matches that wildmat expression or
101 netblock, each <res-program> (multiple res: lines may be present in a
102 block; they are run in sequence until one succeeds), if any, is run to
103 determine the identity of the user just from the connection informa‐
104 tion. If all the resolvers fail, or if the res: parameter isn't
105 present, the user is assigned an identity of "<defuser>@<defdomain>";
106 in other words, the values of the default: and default-domain: parame‐
107 ters are used. If <res-program> only returns a username, <defdomain>
108 is used as the domain.
109 If the user later authenticates via the AUTHINFO USER/PASS commands,
111 the provided username and password are passed to each <auth-program>
112 (multiple auth, perl_auth, or python_auth lines may be present in a
113 block; they are run in sequence until one succeeds), if any. If one
114 succeeds and returns a different identity than the one assigned at the
115 time of the connection, it is matched against the available access
116 groups again and the actions the user is authorized to do may change.
117 The most common <auth-program> to use is ckpasswd, which supports sev‐
118 eral ways of checking passwords including using PAM. See the
119 ckpasswd(8) man page for more details.
120 When matching auth groups, the last auth group in the file that matches
122 a given connection and username/password combination is used.
123 An access group definition usually looks like:
125 access <name> {
127 users: <identity-wildmat>
128 newsgroups: <group-wildmat>
129 # ...possibly other settings
130 }
131 Again, <name> is just for documentation purposes. This says that all
133 users whose identity matches <identity-wildmat> can read and post to
134 all newsgroups matching <group-wildmat> (as before, comma-separated
135 wildmat expressions are allowed, but "@" is not supported). Alter‐
136 nately, you can use the form:
137 access <name> {
139 users: <identity-wildmat>
140 read: <read-wildmat>
141 post: <post-wildmat>
142 }
143 and matching users will be able to read any group that matches
145 <read-wildmat> and post to any group that matches <post-wildmat>. You
146 can also set several other things in the access group as well as over‐
147 ride various inn.conf(5) parameters for just a particular group of
148 users.
149 Just like with auth groups, when matching access groups the last match‐
151 ing one in the file is used to determine the user's permissions. There
152 is an exception to this rule: if the auth group which matched the
153 client contains a perl_access: or python_access: parameter, then the
154 script given as argument is used to dynamically generate an access
155 group. This new access group is then used to determine the access
156 rights of the client; the access groups in the file are ignored.
157 There is one additional special case to be aware of. When forming par‐
159 ticularly complex authentication and authorization rules, it is some‐
160 times useful for the identities provided by a given auth group to only
161 apply to particular access groups; in other words, rather than checking
162 the identity against the users: parameter of every access group, it's
163 checked against the users: parameter of only some specific access
164 groups. This is done with the key: parameter. For example:
165 auth example {
167 key: special
168 hosts: *.example.com
169 default: <SPECIAL>
170 }
171 access example {
173 key: special
174 users: <SPECIAL>
175 newsgroups: *
176 }
177 In this case, the two key: parameters bind this auth group with this
179 access group. For any incoming connection matching "*.example.com"
180 (assuming there isn't any later auth group that also matches such
181 hosts), no access group that doesn't have "key: special" will even be
182 considered. Similarly, the above access group will only be checked if
183 the user was authenticated with an auth group containing "key: spe‐
184 cial". This mechanism normally isn't useful; there is almost always a
185 better way to achieve the same result.
186 Also note in the example that there's no default-domain: parameter,
188 which means that no domain is appended to the default username and the
189 identity for such connections is just "<SPECIAL>". Note that some
190 additional add-ons to INN may prefer that authenticated identities
191 always return a full e-mail address (including a domain), so you may
192 want to set up your system that way.
193 Below is the full list of allowable parameters for auth groups and
195 access groups, and after that are some examples that may make this
196 somewhat clearer.
197
199 An access group without at least one of the res:, auth:, perl_auth:,
200 python_auth:, or default: parameters makes no sense (and in practice
201 will just be ignored).
202 hosts:
204 A comma-separated list of remote hosts, wildmat patterns matching
205 either hostnames or IP addresses, or IP netblocks specified in CIDR
206 notation. If a user connects from a host that doesn't match this
207 parameter, this auth group will not match the connection and is
208 ignored.
209 Note that if you have a large number of patterns that can't be
211 merged into broader patterns (such as a large number of individual
212 systems scattered around the net that should have access), the
213 hosts: parameter may exceed the maximum line length of 8,192 char‐
214 acters. In that case, you'll need to break that auth group into
215 multiple auth groups, each with a portion of the hosts listed in
216 its hosts: parameter, and each assigning the same user identity.
217 All hosts match if this parameter is not given.
219 localaddress:
221 A comma-separated list of local host or address patterns with the
222 same syntax as the same as with the hosts: parameter. If this
223 parameter is specified, its auth group will only match connections
224 made to a matching local interface. (Obviously, this is only use‐
225 ful for servers with multiple interfaces.)
226 All local addresses match if this parameter is not given.
228 res:
230 A simple command line for a user resolver (shell metacharacters are
231 not supported). If a full path is not given, the program executed
232 must be in the pathbin/auth/resolv directory. A resolver is an
233 authentication program which attempts to figure out the identity of
234 the connecting user using nothing but the connection information
235 (in other words, the user has not provided a username and pass‐
236 word). An examples of a resolver would be a program that assigns
237 an identity from an ident callback or from the user's hostname.
238 One auth group can have multiple res: parameters, and they will be
240 tried in the order they're listed. The results of the first suc‐
241 cessful one will be used.
242 auth:
244 A simple command line for a user authenticator (shell metacharac‐
245 ters are not supported). If a full path is not given, the program
246 executed must be located in the pathbin/auth/passwd directory. An
247 authenticator is a program used to handle a user-supplied username
248 and password, via a mechanism such as AUTHINFO USER/PASS. Like
249 with res:, one auth group can have multiple auth: parameters; they
250 will be tried in order and the results of the first successful one
251 will be used. See also perl_auth: below.
252 The most common authenticator to use is ckpasswd(8); see its man
254 page for more information.
255 perl_auth:
257 A path to a perl script for authentication. The perl_auth: parame‐
258 ter works exactly like auth:, except that it calls the named script
259 using the perl hook rather then an external program. Multi‐
260 ple/mixed use of the auth, perl_auth, and python_auth parameters is
261 permitted within any auth group; each line is tried in the order it
262 appears. perl_auth: has more power than auth: in that it provides
263 the authentication program with additional information about the
264 client and the ability to return an error string and a username.
265 This parameter is only valid if INN is compiled with Perl support
266 (--with-perl passed to configure). More information may be found
267 in doc/hook-perl.
268 python_auth:
270 A python script for authentication. The python_auth: parameter
271 works exactly like auth:, except that it calls the named script
272 using the python hook rather then an external program. Multi‐
273 ple/mixed use of the auth, perl_auth, and python_auth parameters is
274 permitted within any auth group; each line is tried in the order it
275 appears. python_auth: has more power than auth: in that it pro‐
276 vides the authentication program with additional information about
277 the client and the ability to return an error string and a user‐
278 name. This parameter is only valid if INN is compiled with Python
279 support (--with-python passed to configure). More information may
280 be found in doc/hook-python.
281 default:
283 The default username for connections matching this auth group.
284 This is the username assigned to the user at connection time if all
285 resolvers fail or if there are no res: parameters. Note that it
286 can be either a bare username, in which case default-domain: (if
287 present) is appended after an "@", or a full identity string con‐
288 taining an "@", in which case it will be used verbatim.
289 default-domain:
291 The default domain string for this auth group. If a user resolver
292 or authenticator doesn't provide a domain, or if the default user‐
293 name is used and it doesn't contain a "@", this domain is used to
294 form the user identity. (Note that for a lot of setups, it's not
295 really necessary for user identities to be qualified with a domain
296 name, in which case there's no need to use this parameter.)
297 key:
299 If this parameter is present, any connection matching this auth
300 group will have its privileges determined only by the subset of
301 access groups containing a matching key parameter.
302 require_ssl:
304 If set to true, an incoming connection only matches this auth group
305 if it is encrypted using SSL. This parameter is only valid if INN
306 is compiled with SSL support (--with-openssl passed to configure).
307 perl_access:
309 A path to a perl script for dynamically generating an access group.
310 If an auth group matches successfully and contains a perl_access
311 parameter, then the argument perl script will be used to create an
312 access group. This group will then determine the access rights of
313 the client, overriding any access groups in readers.conf. If and
314 only if a sucessful auth group contains the perl_access parameter,
315 readers.conf access groups are ignored and the client's rights are
316 instead determined dynamically. This parameter is only valid if
317 INN is compiled with Perl support (--with-perl passed to config‐
318 ure). More information may be found in the file doc/hook-perl.
319 python_access:
321 A python script for dynamically generating an access group. If an
322 auth group matches successfully and contains a python_access param‐
323 eter, then the argument script will be used to create an access
324 group. This group will then determine the access rights of the
325 client, overriding any access groups in readers.conf. If and only
326 if a successful auth group contains the python_access parameter,
327 readers.conf access groups are ignored and the client's rights are
328 instead determined dynamically. This parameter is only valid if
329 INN is compiled with Python support (--with-python passed to con‐
330 figure). More information may be found in the file
331 doc/hook-python.
332 python_dynamic:
334 A python script for applying access control dynamically on a per
335 newsgroup basis. If an auth group matches successfully and con‐
336 tains a python_dynamic parameter, then the argument script will be
337 used to determine the clients rights each time the user attempts to
338 view a newsgroup, or read or post an article. Access rights as
339 determined by python_dynamic override the values of access group
340 parameters such as newsgroups, read, and post. This parameter is
341 only valid if INN is compiled with Python support (--with-python
342 passed to configure). More information may be found in the file
343 doc/hook-python.
344
346 users:
347 The privileges given by this access group apply to any user iden‐
348 tity which matches this comma-separated list of wildmat patterns.
349 If this parameter isn't given, the access group applies to all
350 users (and is essentially equivalent to "users: *").
351 newsgroups:
353 Users that match this access group are allowed to read and post to
354 all newsgroups matching this comma-separated list of wildmat pat‐
355 terns. The empty string is equivalent to "newsgroups: *"; if this
356 parameter is missing, the connection will be rejected (unless read:
357 and/or post: are used instead, see below).
358 read:
360 Like the newsgroups: parameter, but the client is only given per‐
361 mission to read the matching newsgroups. This parameter is often
362 used with post: (below) to specify some read-only groups; it cannot
363 be used in the same access group with a newsgroups: parameter. (If
364 read: is used and post: is missing, the client will have only read-
365 only access.)
366 post:
368 Like the newsgroups: parameter, but the client is only given per‐
369 mission to post to the matching newsgroups. This parameter is
370 often used with read: (above) to define the patterns for reading
371 and posting separately (usually to give the user permission to read
372 more newsgroups than they're permitted to post to). It cannot be
373 used in the same access group with a newsgroups: parameter.
374 access:
376 A set of letters specifying the permissions granted to the client.
377 The letters are chosen from the following set:
378 R The client may read articles.
380 P The client may post articles.
382 I The client may inject articles with IHAVE. Note that in order
384 to inject articles with the IHAVE the user must also have POST
385 permission (the "P" option).
386 A The client may post articles with Approved: headers (in other
388 words, may approve articles for moderated newsgroups). By
389 default, this is not allowed.
390 N The client may use the NEWNEWS command, overriding the global
392 setting.
393 L The client may post to newsgroups that are set to disallow local
395 posting (mode "n" in the active(5) file).
396 Note that if this parameter is given, allownewnews in inn.conf is
398 ignored for connections matching this access group and the ability
399 of the client to use NEWNEWS is entirely determined by the presence
400 of "N" in the access string. If you want to support NEWNEWS, make
401 sure to include "N" in the access string when you use this parame‐
402 ter.
403 Note that if this parameter is given and "R" isn't present in the
405 access string, the client cannot read regardless of newsgroups: or
406 read: parameters. Similarly, if this parameter is given and "P"
407 isn't present, the client cannot post. This use of access: is dep‐
408 recated and confusing; it's strongly recommended that if the
409 access: parameter is used, "R" and "P" always be included in the
410 access string and newsgroups:, read:, and post: be used to control
411 access. (To grant read access but no posting access, one can have
412 just a read: parameter and no post: parameter.)
413 key:
415 If this parameter is present, this access group is only considered
416 when finding privileges for users matching auth groups with this
417 same key: parameter.
418 reject_with:
420 If this parameter is present, a client matching this block will be
421 disconnected with a "Permission denied" message containing the con‐
422 tents (a "reason" string) of this parameter. Some newsreaders will
423 then display the reason to the user.
424 max_rate:
426 If this parameter is present (and nonzero) it is used for nnrpd's
427 rate-limiting code. The client will only be able to download at
428 this speed (in bytes/second). Note that if SSL is being used, lim‐
429 iting is applied to the pre-encryption datastream.
430 localtime:
432 If a Date: header is not included in a posted article, nnrpd(8)
433 normally adds a new Date: header in UTC. If this is set to true,
434 the Date: header will be formatted in local time instead. This is
435 a boolean value and the default is false.
436 newsmaster:
438 Used as the contact address in the help message returned by
439 nnrpd(8), if the virtualhost: parameter is set to true.
440 strippath:
442 If set to true, any Path: header provided by a user in a post is
443 stripped rather than used as the beginning of the Path: header of
444 the article. This is a boolean value and the default is false.
445 perlfilter:
447 If set to false, posts made by these users do not pass through the
448 Perl filter even if it is otherwise enabled. This is a boolean
449 value and the default is true.
450 pythonfilter:
452 If set to false, posts made by these users do not pass through the
453 Python filter even if it is otherwise enabled. This is a boolean
454 value and the default is true.
455 virtualhost:
457 Set this parameter to make nnrpd behave as if it's running on a
458 server with a different name than it actually is. If you set this
459 parameter, you must also set either pathhost: or domain: to some‐
460 thing different than is set in inn.conf. All articles displayed to
461 clients will then have their Path: and Xref: headers altered to
462 appear to be from the server named in pathhost: or domain: (which‐
463 ever is set), and posted articles will use that server name in the
464 Path:, Message-ID;, and X-Trace: headers.
465 Note that setting this parameter requires the server modify all
467 posts before presenting them to the client and therefore may
468 decrease performance slightly.
469 In addition, all of the following parameters are valid in access groups
471 and override the global setting in inn.conf. See inn.conf(5) for the
472 descriptions of these parameters: addnntppostingdate, addnntppost‐
473 inghost, backoff_auth, backoff_db, backoff_k, backoff_postfast, back‐
474 off_postslow, backoff_trigger, checkincludedtext, clienttimeout, com‐
475 plaints, domain, fromhost, localmaxartsize, moderatormailer, nnrpdauth‐
476 sender, nnrpdcheckart, nnrpdoverstats, nnrpdposthost, nnrpdpostport,
477 organization, pathhost, readertrack, spoolfirst, and strippostcc.
478
480 Here's a basic summary of what happens when a client connects:
481 · All auth groups are scanned and the ones that don't match the client
483 (due to hosts:, localaddress:, require_ssl:, etc) are eliminated.
484 · The remaining auth groups are scanned from the last to the first, and
486 an attempt is made to apply it to the current connection. This means
487 running res: programs, if any, and otherwise applying default:. The
488 first auth group (starting from the bottom) to return a valid user is
489 kept as the active auth group.
490 · If no auth groups yield a valid user (none have default: parameters
492 or successful res: programs) but some of the auth groups have auth:
493 lines (indicating a possibility that the user can authenticate and
494 then obtain permissions), the connection is considered to have no
495 valid auth group (which means that the access groups are ignored com‐
496 pletely) but the connection isn't closed. Instead, 480 is returned
497 for everything until the user authenticates.
498 · When the user authenticates, the auth groups are rescanned, and only
500 the matching ones which contain at least one auth, perl_auth, or
501 python_auth line are considered. These auth groups are scanned from
502 the last to the first, running auth: programs and perl_auth: or
503 python_auth: scripts. The first auth group (starting from the bot‐
504 tom) to return a valid user is kept as the active auth group.
505 · Regardless of how an auth group is established, as soon as one is,
507 that auth group is used to assign a user identity by taking the
508 result of the successful res, auth, perl_auth, or python_auth line
509 (or the default: if necessary), and appending the default-domain if
510 necessary. (If the perl_access: or python_access: parameter is
511 present, see below.)
512 · Finally, an access group is selected by scanning the access groups
514 from bottom up and finding the first match. (If the established auth
515 group contained a perl_access: or python_access line, the dynamically
516 generated access group returned by the script is used instead.) User
517 permissions are granted based on the established access group.
518
520 Probably the simplest useful example of a complete readers.conf, this
521 gives permissions to read and post to all groups to any connections
522 from the "example.com" domain, and no privileges for anyone connecting
523 elsewhere:
524 auth example.com {
526 hosts: "*.example.com, example.com"
527 default: <LOCAL>
528 }
529 access full {
531 newsgroups: *
532 }
533 Note that the access realm has no users: key and therefore applies to
535 any user identity. The only available auth realm only matches hosts in
536 the "example.com" domain, though, so any connections from other hosts
537 will be rejected immediately.
538 If you have some systems that should only have read-only access to the
540 server, you can modify the example above slightly by adding an addi‐
541 tional auth and access group:
542 auth lab {
544 hosts: "*.lab.example.com"
545 default: <LAB>
546 }
547 access lab {
549 users: <LAB>
550 read: *
551 }
552 If those are put in the file after the above example, they'll take
554 precedence (because they're later in the file) for any user coming from
555 a machine in the lab.example.com domain, everyone will only have read
556 access, not posting access.
557 Here's a similar example for a news server that accepts connections
559 from anywhere but requires the user to specify a username and password.
560 The username and password are first checked against an external data‐
561 base of usernames and passwords, and then against the system shadow
562 password file:
563 auth all {
565 auth: "ckpasswd -d /usr/local/news/db/newsusers"
566 auth: "ckpasswd -s"
567 }
568 access full {
570 users: *
571 newsgroups: *
572 }
573 When the user first connects, there are no res: keys and no default, so
575 they don't receive any valid identity and the connection won't match
576 any access groups (even ones with "users: *"). Such users receive
577 nothing but authentication-required responses from nnrpd until they
578 authenticate.
579 If they then later authenticate, the username and password are checked
581 first by running ckpasswd with the -d option for an external dbm file
582 of encrypted passwords, and then with the -s option to check the shadow
583 password database (note that this option may require ckpasswd to be
584 setgid to a shadow group, and there are security considerations; see
585 ckpasswd(8) for details). If both of those fail, the user will con‐
586 tinue to have no identity; otherwise, an identity will be assigned
587 (usually the supplied username, perhaps with a domain appended,
588 although an authenticator technically can provide a completely differ‐
589 ent username for the identity), and the access group will match, giving
590 full access.
591 It may be educational to consider how to combine the above examples;
593 general groups always go first. The order of the auth groups actually
594 doesn't matter, since the "hosts: example.com" one only matches connec‐
595 tions before username/password is sent, and the "auth: ckpasswd" one
596 only matches after; order would matter if either group applied to both
597 cases. The order of the access groups in this case does matter, pro‐
598 vided the newsgroups: lines differ; the access group with no users:
599 line needs to be first, with the "users: <LOCAL>" group after.
600 Here's a very complicated example. This is for an organization that
602 has an internal hierarchy "example.*" only available to local shell
603 users, who are on machines where identd can be trusted. Dialup users
604 must provide a username and password, which is then checked against
605 RADIUS. Remote users have to use a username and password that's
606 checked against a database on the news server. Finally, the admin
607 staff (users "joe" and "jane") can post anywhere (including the "exam‐
608 ple.admin.*" groups that are read-only for everyone else), and are
609 exempted from the Perl filter. For an additional twist, posts from
610 dialup users have their Sender: header replaced by their authenticated
611 identity.
612 Since this organization has some internal moderated newsgroups, the
614 admin staff can also post messages with Approved: headers, but other
615 users cannot.
616 auth default {
618 auth: "ckpasswd -f /usr/local/news/db/newsusers"
619 default: <FAIL>
620 default-domain: example.com
621 }
622 auth shell {
624 hosts: *.shell.example.com
625 res: ident
626 auth: "ckpasswd -s"
627 default: <FAIL>
628 default-domain: shell.example.com
629 }
630 auth dialup {
632 hosts: *.dialup.example.com
633 auth: radius
634 default: <FAIL>
635 default-domain: dialup.example.com
636 }
637 access shell {
639 users: *@shell.example.com
640 read: *
641 post: "*, !example.admin.*"
642 }
643 access dialup {
645 users: *@dialup.example.com
646 newsgroups: *,!example.*
647 nnrpdauthsender: true
648 }
649 access other {
651 users: "*@example.com, !<FAIL>@example.com"
652 newsgroups: *,!example.*
653 }
654 access fail {
656 users: "<FAIL>@*"
657 newsgroups: !*
658 }
659 access admin {
661 users: "joe@*,jane@*"
662 newsgroups: *
663 access: "RPA"
664 perlfilter: false
665 }
666 Note the use of different domains to separate dialup from shell users
668 easily. Another way to do that would be with key: parameters, but this
669 way provides slightly more intuitive identity strings. Note also that
670 the fail access group catches not only failing connections from exter‐
671 nal users but also failed authentication of shell and dialup users and
672 dialup users before they've authenticated. The identity string given
673 for, say, dialup users before RADIUS authentication has been attempted
674 matches both the dialup access group and the fail access group, since
675 it's "<FAIL>@dialup.example.com", but the fail group is last so it
676 takes precedence.
677 The shell auth group has an auth: parameter so that users joe and jane
679 can, if they choose, use username and password authentication to gain
680 their special privileges even if they're logged on as a different user
681 on the shell machines (or if ident isn't working). When they first
682 connect, they'd have the default access for that user, but they could
683 then send AUTHINFO USER and AUTHINFO PASS (or AUTHINFO SIMPLE) and get
684 their extended access.
685 Also note that if the users joe and jane are using their own accounts,
687 they get their special privileges regardless of how they connect,
688 whether the dialups, the shell machines, or even externally with a
689 username and password.
690 Finally, here's a very simple example of a configuration for a public
692 server for a particular hierarchy.
693 auth default {
695 hosts: *
696 default: <PUBLIC>
697 }
698 access default {
700 users: <PUBLIC>
701 newsgroups: example.*
702 }
703 Notice that clients aren't allowed to read any other groups; this keeps
705 them from getting access to administrative groups or reading control
706 messages, just as a precaution. When running a public server like
707 this, be aware that many public hierarchies will later be pulled down
708 and reinjected into the main Usenet, so it's highly recommended that
709 you also run a Perl or Python filter to reject any messages crossposted
710 out of your local hierarchy and any messages containing a Supersedes:
711 header. This will keep messages posted to your public hierarchy from
712 hurting any of the rest of Usenet if they leak out.
713
715 In general, separate passwords should be used for NNTP wherever possi‐
716 ble; the NNTP protocol itself does not protect passwords from casual
717 interception, and many implementations (including this one) do not
718 "lock out" accounts or otherwise discourage password-guessing attacks.
719 So it is best to ensure that a compromised password has minimal
720 effects.
721 Authentication using the AUTHINFO USER/PASS commands passes unencrypted
723 over the network. Extreme caution should therefore be used especially
724 with system passwords (e.g. "auth: ckpasswd -s"). Passwords can be
725 protected by using NNTP over SSL or through ssh tunnels, and this usage
726 can be enforced by a well-considered server configuration that only
727 permits certain auth groups to be applied in certain cases. Here are
728 some ideas:
729 · To restrict connections on the standard nntp port (119) to use SSL
731 for some (or all) of the auth groups to match, use the require_ssl:
732 parameter.
733 · If you consider your local network (but not the internet) secure,
735 have some auth groups with a restrictive hosts: parameter; they
736 would go above, with ones having global applicability below.
737 · Consider running a "nnrpd -S" (with "-D", or out of "super-server"
739 like inetd) on the nntps port (563) for clients that support SSL.
740 You can use the require_ssl: parameter, or "-c" to specify an
741 alternate readers.conf if you want a substantially different con‐
742 figuration for this case.
743 · If you want to restrict an auth group to only match loopback con‐
745 nections (for users running newsreaders on localhost or connecting
746 via an ssh tunnel), use the localaddress: parameter.
747
749 Written by Aidan Cully <aidan@panix.com> for InterNetNews. Substan‐
750 tially expanded by Russ Allbery <rra@stanford.edu>.
751 $Id: readers.conf.5 7384 2005-07-05 01:28:43Z eagle $
753
755 ckpasswd(8), inn.conf(5), innd(8), newsfeeds(5), nnrpd(8), uwildmat(3)
756INN 2.4.3 2005-07-04 READERS.CONF(5)