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
10 controls 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
26 lowercase), 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
69 documentation 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
83 documentation purposes. (If your syslog configuration records the
84 "news.debug" facility, the <name> will appear in the debugging output
85 of nnrpd. Examining that output can be very helpful in understanding
86 why your 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 (comma-
90 separated wildmat expressions allowed, but "@" is not supported).
91 Rather than wildmat expressions, you may also use CIDR notation to
92 match any IP address in a netblock; for example, "10.10.10.0/24" will
93 match any IP address between 10.10.10.0 and 10.10.10.255 inclusive.
94 If compiled against the TLS/SSL libraries, an auth group with the
96 require_ssl parameter set to true only applies if the incoming
97 connection is using TLS, either from the beginning if the -S flag was
98 passed to nnrpd or after a successful use of STARTTLS.
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
104 information. 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:
107 parameters are used. If <res-program> only returns a username,
108 <defdomain> 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
118 several 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).
136 Alternately, 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
147 override 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
151 matching one in the file is used to determine the user's permissions.
152 There 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
159 particularly complex authentication and authorization rules, it is
160 sometimes useful for the identities provided by a given auth group to
161 only apply to particular access groups; in other words, rather than
162 checking the identity against the users: parameter of every access
163 group, it's checked against the users: parameter of only some specific
164 access 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:
184 special". This mechanism normally isn't useful; there is almost always
185 a 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
214 characters. In that case, you'll need to break that auth group
215 into multiple auth groups, each with a portion of the hosts listed
216 in 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
225 useful 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
236 password). An examples of a resolver would be a program that
237 assigns an identity from an ident callback or from the user's
238 hostname.
239 One auth group can have multiple res: parameters, and they will be
241 tried in the order they're listed. The results of the first
242 successful one will be used.
243 auth:
245 A simple command line for a user authenticator (shell
246 metacharacters are not supported). If a full path is not given,
247 the program executed must be located in the pathbin/auth/passwd
248 directory. An authenticator is a program used to handle a user-
249 supplied username and password, via a mechanism such as AUTHINFO
250 USER/PASS. Like with res:, one auth group can have multiple auth:
251 parameters; they will be tried in order and the results of the
252 first successful one will be used. See also perl_auth: below.
253 The most common authenticator to use is ckpasswd(8); see its man
255 page for more information.
256 perl_auth:
258 A path to a perl script for authentication. The perl_auth:
259 parameter works exactly like auth:, except that it calls the named
260 script using the perl hook rather then an external program.
261 Multiple/mixed use of the auth, perl_auth, and python_auth
262 parameters is permitted within any auth group; each line is tried
263 in the order it appears. perl_auth: has more power than auth: in
264 that it provides the authentication program with additional
265 information about the client and the ability to return an error
266 string and a username. This parameter is only valid if INN is
267 compiled with Perl support (--with-perl passed to configure). More
268 information may be found in doc/hook-perl.
269 python_auth:
271 A Python script for authentication. The python_auth parameter
272 works exactly like auth, except that it calls the named script
273 (without its ".py" extension) using the Python hook rather then an
274 external program. Multiple/mixed use of the auth, perl_auth, and
275 python_auth parameters is permitted within any auth group; each
276 line is tried in the order it appears. python_auth has more power
277 than auth in that it provides the authentication program with
278 additional information about the client and the ability to return
279 an error string and a username. This parameter is only valid if
280 INN is compiled with Python support (--with-python passed to
281 configure). More information may be found in doc/hook-python.
282 default:
284 The default username for connections matching this auth group.
285 This is the username assigned to the user at connection time if all
286 resolvers fail or if there are no res: parameters. Note that it
287 can be either a bare username, in which case default-domain: (if
288 present) is appended after an "@", or a full identity string
289 containing an "@", in which case it will be used verbatim.
290 default-domain:
292 The default domain string for this auth group. If a user resolver
293 or authenticator doesn't provide a domain, or if the default
294 username is used and it doesn't contain a "@", this domain is used
295 to form the user identity. (Note that for a lot of setups, it's
296 not really necessary for user identities to be qualified with a
297 domain name, in which case there's no need to use this parameter.)
298 key:
300 If this parameter is present, any connection matching this auth
301 group will have its privileges determined only by the subset of
302 access groups containing a matching key parameter.
303 require_ssl:
305 If set to true, an incoming connection only matches this auth group
306 if it is encrypted using TLS/SSL, either from the beginning if the
307 -S flag was passed to nnrpd or after a successful use of STARTTLS.
308 This parameter is only valid if INN is compiled with TLS/SSL
309 support (--with-openssl passed to configure).
310 perl_access:
312 A path to a perl script for dynamically generating an access group.
313 If an auth group matches successfully and contains a perl_access
314 parameter, then the argument perl script will be used to create an
315 access group. This group will then determine the access rights of
316 the client, overriding any access groups in readers.conf. If and
317 only if a sucessful auth group contains the perl_access parameter,
318 readers.conf access groups are ignored and the client's rights are
319 instead determined dynamically. This parameter is only valid if
320 INN is compiled with Perl support (--with-perl passed to
321 configure). More information may be found in the file
322 doc/hook-perl.
323 python_access:
325 A Python script for dynamically generating an access group. If an
326 auth group matches successfully and contains a python_access
327 parameter, then the argument script (without its ".py" extension)
328 will be used to create an access group. This group will then
329 determine the access rights of the client, overriding any access
330 groups in readers.conf. If and only if a successful auth group
331 contains the python_access parameter, readers.conf access groups
332 are ignored and the client's rights are instead determined
333 dynamically. This parameter is only valid if INN is compiled with
334 Python support (--with-python passed to configure). More
335 information may be found in the file doc/hook-python.
336 python_dynamic:
338 A Python script for applying access control dynamically on a per
339 newsgroup basis. If an auth group matches successfully and
340 contains a python_dynamic parameter, then the argument script
341 (without its ".py" extension) will be used to determine the clients
342 rights each time the user attempts to view a newsgroup, or read or
343 post an article. Access rights as determined by python_dynamic
344 override the values of access group parameters such as newsgroups,
345 read and post. This parameter is only valid if INN is compiled
346 with Python support (--with-python passed to configure). More
347 information may be found in the file doc/hook-python.
348
350 users:
351 The privileges given by this access group apply to any user
352 identity which matches this comma-separated list of wildmat
353 patterns. If this parameter isn't given, the access group applies
354 to all users (and is essentially equivalent to "users: *").
355 newsgroups:
357 Users that match this access group are allowed to read and post to
358 all newsgroups matching this comma-separated list of wildmat
359 patterns. The empty string is equivalent to "newsgroups: *"; if
360 this parameter is missing, the connection will be rejected (unless
361 read: and/or post: are used instead, see below).
362 read:
364 Like the newsgroups: parameter, but the client is only given
365 permission to read the matching newsgroups. This parameter is
366 often used with post: (below) to specify some read-only groups; it
367 cannot be used in the same access group with a newsgroups:
368 parameter. (If read: is used and post: is missing, the client will
369 have only read-only access.)
370 post:
372 Like the newsgroups: parameter, but the client is only given
373 permission to post to the matching newsgroups. This parameter is
374 often used with read: (above) to define the patterns for reading
375 and posting separately (usually to give the user permission to read
376 more newsgroups than they're permitted to post to). It cannot be
377 used in the same access group with a newsgroups: parameter.
378 access:
380 A set of letters specifying the permissions granted to the client.
381 The letters are chosen from the following set:
382 R The client may read articles.
384 P The client may post articles.
386 I The client may inject articles with IHAVE. Note that in order
388 to inject articles with the IHAVE the user must also have POST
389 permission (the "P" option).
390 A The client may post articles with Approved: headers (in other
392 words, may approve articles for moderated newsgroups). By
393 default, this is not allowed.
394 N The client may use the NEWNEWS command, overriding the global
396 setting.
397 L The client may post to newsgroups that are set to disallow local
399 posting (status fields "j", "n" and "x" in the active(5) file).
400 Note that if this parameter is given, allownewnews in inn.conf is
402 ignored for connections matching this access group and the ability
403 of the client to use NEWNEWS is entirely determined by the presence
404 of "N" in the access string. If you want to support NEWNEWS, make
405 sure to include "N" in the access string when you use this
406 parameter.
407 Note that if this parameter is given and "R" isn't present in the
409 access string, the client cannot read regardless of newsgroups: or
410 read: parameters. Similarly, if this parameter is given and "P"
411 isn't present, the client cannot post. This use of access: is
412 deprecated and confusing; it's strongly recommended that if the
413 access: parameter is used, "R" and "P" always be included in the
414 access string and newsgroups:, read:, and post: be used to control
415 access. (To grant read access but no posting access, one can have
416 just a read: parameter and no post: parameter.)
417 key:
419 If this parameter is present, this access group is only considered
420 when finding privileges for users matching auth groups with this
421 same key: parameter.
422 reject_with:
424 If this parameter is present, a client matching this block will be
425 disconnected with a "Permission denied" message containing the
426 contents (a "reason" string) of this parameter. Some newsreaders
427 will then display the reason to the user.
428 max_rate:
430 If this parameter is present (and nonzero), it is used for nnrpd's
431 rate-limiting code. The client will only be able to download at
432 this speed (in bytes/second). Note that if TLS/SSL is being used,
433 limiting is applied to the pre-encryption datastream.
434 localtime:
436 If a Date: header is not included in a posted article, nnrpd(8)
437 normally adds a new Date: header in UTC. If this is set to true,
438 the Date: header will be formatted in local time instead. This is
439 a boolean value and the default is false.
440 newsmaster:
442 Used as the contact address in the help message returned by
443 nnrpd(8), if the virtualhost: parameter is set to true.
444 strippath:
446 If set to true, any Path: header provided by a user in a post is
447 stripped rather than used as the beginning of the Path: header of
448 the article. This is a boolean value and the default is false.
449 perlfilter:
451 If set to false, posts made by these users do not pass through the
452 Perl filter even if it is otherwise enabled. This is a boolean
453 value and the default is true.
454 pythonfilter:
456 If set to false, posts made by these users do not pass through the
457 Python filter even if it is otherwise enabled. This is a boolean
458 value and the default is true.
459 virtualhost:
461 Set this parameter to true in order to make nnrpd behave as if it
462 is running on a server with a different name than it actually is.
463 If you set this parameter to true, you must also set either
464 pathhost: or domain: in the relevant access group in readers.conf
465 to something different than is set in inn.conf. All articles
466 displayed to clients will then have their Path: and Xref: headers
467 altered to appear to be from the server named in pathhost: or
468 domain: (whichever is set), and posted articles will use that
469 server name in the Path:, Message-ID:, and X-Trace: headers.
470 Note that setting this parameter requires the server modify all
472 posts before presenting them to the client and therefore may
473 decrease performance slightly.
474 In addition, all of the following parameters are valid in access groups
476 and override the global setting in inn.conf. See inn.conf(5) for the
477 descriptions of these parameters:
478 addnntppostingdate, addnntppostinghost, backoff_auth, backoff_db,
480 backoff_k, backoff_postfast, backoff_postslow, backoff_trigger,
481 checkincludedtext, clienttimeout, complaints, domain,
482 fromhost, localmaxartsize, moderatormailer, nnrpdauthsender,
483 nnrpdcheckart, nnrpdoverstats, nnrpdposthost, nnrpdpostport, organization,
484 pathhost, readertrack, spoolfirst, strippostcc.
485
487 Here's a basic summary of what happens when a client connects:
488 · All auth groups are scanned and the ones that don't match the client
490 (due to hosts, localaddress, require_ssl, etc.) are eliminated.
491 · The remaining auth groups are scanned from the last to the first, and
493 an attempt is made to apply it to the current connection. This means
494 running res: programs, if any, and otherwise applying default:. The
495 first auth group (starting from the bottom) to return a valid user is
496 kept as the active auth group.
497 · If no auth groups yield a valid user (none have default: parameters
499 or successful res: programs) but some of the auth groups have auth:
500 lines (indicating a possibility that the user can authenticate and
501 then obtain permissions), the connection is considered to have no
502 valid auth group (which means that the access groups are ignored
503 completely) but the connection isn't closed. Instead, 480 is
504 returned for everything until the user authenticates.
505 · When the user authenticates, the auth groups are rescanned, and only
507 the matching ones which contain at least one auth, perl_auth, or
508 python_auth line are considered. These auth groups are scanned from
509 the last to the first, running auth: programs and perl_auth: or
510 python_auth: scripts. The first auth group (starting from the
511 bottom) to return a valid user is kept as the active auth group.
512 · Regardless of how an auth group is established, as soon as one is,
514 that auth group is used to assign a user identity by taking the
515 result of the successful res, auth, perl_auth, or python_auth line
516 (or the default: if necessary), and appending the default-domain if
517 necessary. (If the perl_access: or python_access: parameter is
518 present, see below.)
519 · Finally, an access group is selected by scanning the access groups
521 from bottom up and finding the first match. (If the established auth
522 group contained a perl_access: or python_access line, the dynamically
523 generated access group returned by the script is used instead.) User
524 permissions are granted based on the established access group.
525
527 Probably the simplest useful example of a complete readers.conf, this
528 gives permissions to read and post to all groups to any connections
529 from the "example.com" domain, and no privileges for anyone connecting
530 elsewhere:
531 auth example.com {
533 hosts: "*.example.com, example.com"
534 default: <LOCAL>
535 }
536 access full {
538 newsgroups: *
539 }
540 Note that the access realm has no users: key and therefore applies to
542 any user identity. The only available auth realm only matches hosts in
543 the "example.com" domain, though, so any connections from other hosts
544 will be rejected immediately.
545 If you have some systems that should only have read-only access to the
547 server, you can modify the example above slightly by adding an
548 additional auth and access group:
549 auth lab {
551 hosts: "*.lab.example.com"
552 default: <LAB>
553 }
554 access lab {
556 users: <LAB>
557 read: *
558 }
559 If those are put in the file after the above example, they'll take
561 precedence (because they're later in the file) for any user coming from
562 a machine in the lab.example.com domain, everyone will only have read
563 access, not posting access.
564 Here's a similar example for a news server that accepts connections
566 from anywhere but requires the user to specify a username and password.
567 The username and password are first checked against an external
568 database of usernames and passwords, and then against the system shadow
569 password file:
570 auth all {
572 auth: "ckpasswd -d <pathdb in inn.conf>/newsusers"
573 auth: "ckpasswd -s"
574 }
575 access full {
577 users: *
578 newsgroups: *
579 }
580 When the user first connects, there are no res: keys and no default, so
582 they don't receive any valid identity and the connection won't match
583 any access groups (even ones with "users: *"). Such users receive
584 nothing but authentication-required responses from nnrpd until they
585 authenticate.
586 If they then later authenticate, the username and password are checked
588 first by running ckpasswd with the -d option for an external dbm file
589 of encrypted passwords, and then with the -s option to check the shadow
590 password database (note that this option may require ckpasswd to be
591 setgid to a shadow group, and there are security considerations; see
592 ckpasswd(8) for details). If both of those fail, the user will
593 continue to have no identity; otherwise, an identity will be assigned
594 (usually the supplied username, perhaps with a domain appended,
595 although an authenticator technically can provide a completely
596 different username for the identity), and the access group will match,
597 giving full access.
598 It may be educational to consider how to combine the above examples;
600 general groups always go first. The order of the auth groups actually
601 doesn't matter, since the "hosts: example.com" one only matches
602 connections before username/password is sent, and the "auth: ckpasswd"
603 one only matches after; order would matter if either group applied to
604 both cases. The order of the access groups in this case does matter,
605 provided the newsgroups: lines differ; the access group with no users:
606 line needs to be first, with the "users: <LOCAL>" group after.
607 Here's an example of another common case: a server that only allows
609 connections from a local domain and has an additional hierarchy that's
610 password-restricted.
611 auth "example.com" {
613 hosts: "*.example.com"
614 auth: "ckpasswd -d <pathdb in inn.conf>/newsusers"
615 default: "anonymous"
616 }
617 access regular {
619 newsgroups: "*,!example.restricted.*"
620 }
621 access full {
623 users: "*,!anonymous"
624 newsgroups: *
625 }
626 In this example, unauthenticated users get the identity "anonymous",
628 which matches only the first access group and hence doesn't get access
629 to the example.restricted.* hierarchy. Anyone who authenticates using
630 a password in the newsusers file gets full access to all groups.
631 However, note that the only authentication block is limited to
632 hostnames in the example.com domain; connections outside of that domain
633 will never be allowed access or an opportunity to authenticate.
634 Here's a very complicated example. This is for an organization that
636 has an internal hierarchy "example.*" only available to local shell
637 users, who are on machines where identd can be trusted. Dialup users
638 must provide a username and password, which is then checked against
639 RADIUS. Remote users have to use a username and password that's
640 checked against a database on the news server. Finally, the admin
641 staff (users "joe" and "jane") can post anywhere (including the
642 "example.admin.*" groups that are read-only for everyone else), and are
643 exempted from the Perl filter. For an additional twist, posts from
644 dialup users have their Sender: header replaced by their authenticated
645 identity.
646 Since this organization has some internal moderated newsgroups, the
648 admin staff can also post messages with Approved: headers, but other
649 users cannot.
650 auth default {
652 auth: "ckpasswd -f <pathdb in inn.conf>/newsusers"
653 default: <FAIL>
654 default-domain: example.com
655 }
656 auth shell {
658 hosts: *.shell.example.com
659 res: ident
660 auth: "ckpasswd -s"
661 default: <FAIL>
662 default-domain: shell.example.com
663 }
664 auth dialup {
666 hosts: *.dialup.example.com
667 auth: radius
668 default: <FAIL>
669 default-domain: dialup.example.com
670 }
671 access shell {
673 users: *@shell.example.com
674 read: *
675 post: "*, !example.admin.*"
676 }
677 access dialup {
679 users: *@dialup.example.com
680 newsgroups: *,!example.*
681 nnrpdauthsender: true
682 }
683 access other {
685 users: "*@example.com, !<FAIL>@example.com"
686 newsgroups: *,!example.*
687 }
688 access fail {
690 users: "<FAIL>@*"
691 newsgroups: !*
692 }
693 access admin {
695 users: "joe@*,jane@*"
696 newsgroups: *
697 access: "RPA"
698 perlfilter: false
699 }
700 Note the use of different domains to separate dialup from shell users
702 easily. Another way to do that would be with key: parameters, but this
703 way provides slightly more intuitive identity strings. Note also that
704 the fail access group catches not only failing connections from
705 external users but also failed authentication of shell and dialup users
706 and dialup users before they've authenticated. The identity string
707 given for, say, dialup users before RADIUS authentication has been
708 attempted matches both the dialup access group and the fail access
709 group, since it's "<FAIL>@dialup.example.com", but the fail group is
710 last so it takes precedence.
711 The shell auth group has an auth: parameter so that users joe and jane
713 can, if they choose, use username and password authentication to gain
714 their special privileges even if they're logged on as a different user
715 on the shell machines (or if ident isn't working). When they first
716 connect, they'd have the default access for that user, but they could
717 then send AUTHINFO USER and AUTHINFO PASS in order to get their
718 extended access.
719 Also note that if the users joe and jane are using their own accounts,
721 they get their special privileges regardless of how they connect,
722 whether the dialups, the shell machines, or even externally with a
723 username and password.
724 Finally, here's a very simple example of a configuration for a public
726 server for a particular hierarchy.
727 auth default {
729 hosts: *
730 default: <PUBLIC>
731 }
732 access default {
734 users: <PUBLIC>
735 newsgroups: example.*
736 }
737 Notice that clients aren't allowed to read any other groups; this keeps
739 them from getting access to administrative groups or reading control
740 messages, just as a precaution. When running a public server like
741 this, be aware that many public hierarchies will later be pulled down
742 and reinjected into the main Usenet, so it's highly recommended that
743 you also run a Perl or Python filter to reject any messages crossposted
744 out of your local hierarchy and any messages containing a Supersedes:
745 header. This will keep messages posted to your public hierarchy from
746 hurting any of the rest of Usenet if they leak out.
747
749 In general, separate passwords should be used for NNTP wherever
750 possible; the NNTP protocol itself does not protect passwords from
751 casual interception, and many implementations (including this one) do
752 not "lock out" accounts or otherwise discourage password-guessing
753 attacks. So it is best to ensure that a compromised password has
754 minimal effects.
755 Authentication using the AUTHINFO USER/PASS commands passes unencrypted
757 over the network. Extreme caution should therefore be used especially
758 with system passwords (e.g. "auth: ckpasswd -s"). Passwords can be
759 protected by using NNTP over TLS/SSL or through ssh tunnels, and this
760 usage can be enforced by a well-considered server configuration that
761 only permits certain auth groups to be applied in certain cases. Here
762 are some ideas:
763 · To restrict connections on the standard NNTP port (119) to use TLS
765 for some (or all) of the auth groups to match, use the require_ssl
766 parameter. Note that a client can use STARTTLS to negotiate an
767 encrypted connection. A secure layer can also be negotiated during
768 authentication via AUTHINFO SASL.
769 · If you consider your local network (but not the internet) secure,
771 have some auth groups with a restrictive hosts: parameter; they
772 would go above, with ones having global applicability below.
773 · Consider running nnrpd with the -S flag (either also with -D, or
775 out of "super-server" like inetd) on the NNTPS port (563) for
776 clients that support TLS/SSL. See nnrpd(8) for more details about
777 how to configure that. You can use the require_ssl parameter or
778 the -c flag to specify an alternate readers.conf file if you want a
779 substantially different configuration for this case.
780 · If you want to restrict an auth group to only match loopback
782 connections (for users running newsreaders on localhost or
783 connecting via an ssh tunnel), use the localaddress: parameter.
784
786 Written by Aidan Cully <aidan@panix.com> for InterNetNews.
787 Substantially expanded by Russ Allbery <rra@stanford.edu>.
788 $Id: readers.conf.pod 9031 2010-03-23 18:31:55Z iulius $
790
792 auth_krb5(8), ckpasswd(8), inn.conf(5), innd(8), newsfeeds(5),
793 nnrpd(8), uwildmat(3).
794INN 2.5.2 2010-08-11 READERS.CONF(5)