This file is indexed.

/etc/news/readers.conf is in inn2 2.5.3-3ubuntu1.

This file is owned by root:root, with mode 0o644.

The actual contents of the file can be viewed below.

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
##  $Id: readers.conf 7828 2008-05-07 07:58:22Z iulius $
##
##  readers.conf - Access control and configuration for nnrpd
##
##  Format:
##	auth "<name>" {
##		hosts: "<hostlist>"
##		auth: "<authprog>"
##		res: "<resprog>"
##		default: "<identity>"
##		default-domain: "<email-domain>"
##	}
##	access "<name>" {
##		users: "<userlist>"
##		newsgroups: "<newsgroups>"
##		read: "<read>"
##		post: "<post>"
##		access: "<perm>"
##	}
##
##  Other parameters are possible.  See readers.conf(5) for all the
##  details.  Only one of newsgroups or read/post may be used in a single
##  access group.
##
##  If the connecting host is not matched by any hosts: parameter of any
##  auth group, it will be denied access.  auth groups assign an identity
##  string to connections, access groups grant privileges to identity
##  strings matched by their users: parameters.
##
##  In all cases, the last match found is used, so put defaults first.
##
##  For a news server that allows connections from anyone within a
##  particular domain or IP address range, just uncomment the "local" auth
##  group and the "local" access group below and adjust the hosts: and
##  default: parameters of the auth group and the users: parameter of the
##  access group for your local network and domain name.  That's all there
##  is to it.
##
##  For more complicated configurations, read the comments on the examples
##  and also see the examples and explanations in readers.conf(5).  The
##  examples in readers.conf(5) include setups that require the user to
##  log in with a username and password (the example in this file only
##  uses simple host-based authentication).
##
##  NOTE: Unlike in previous versions of INN, nnrpd will now refuse any
##  post from anyone to a moderated newsgroup that contains an Approved:
##  header unless their access block has an access: key containing the
##  "A" flag.  This is to prevent abuse of moderated groups, but it means
##  that if you support any newsgroup moderators, you need to make sure
##  to add such a line to the access group that affects them.  See the
##  access group for localhost below for an example.

# The only groups enabled by default (the rest of this file is
# commented-out examples).  This assigns the identity of <localhost> to
# the local machine

auth "localhost" {
    hosts: "localhost, 127.0.0.1, ::1, stdin"
    default: "<localhost>"
}

# Grant that specific identity access to read and post to any newsgroup
# and allow it to post articles with Approved: headers to moderated
# groups.

access "localhost" {
    users: "<localhost>"
    newsgroups: "*"
    access: RPA
}


# This auth group matches all connections from example.com or machines in
# the example.com domain and gives them the identity <local>@example.com.
# Instead of using wildmat patterns to match machine names, you could also
# put a wildmat pattern matching IP addresses or an IP range specified
# using CIDR notation (like 10.10.10.0/24) here.

#auth "local" {
#    hosts: "*.example.com, example.com"
#    default: "<local>@example.com"
#}

# This auth group matches a subset of machines and assigns connections
# from there an identity of "<read>@example.com"; these systems should
# only have read access, no posting privileges.

#auth "read-only" {
#    hosts: "*.newuser.example.com"
#    default: "<read>@example.com"
#}

# This auth group matches the systems at a guest institution that should
# be allowed to read the example.events.* hierarchy but nothing else.

#auth "events-only" {
#    hosts: "*.example.org"
#    default: "<events-only>@example.org"
#}

# Finally, this auth group matches some particular systems which have been
# abusing the server.  Note that it doesn't assign them an identity at
# all; the "empty" identity created in this fashion won't match any users:
# parameters.  Note also that it's last, so anything matching this entry
# will take precedent over everything above it.

#auth "abusers" {
#    hosts: "badguy-dsl.example.com, kiosk.public-access.example.com"
#}


# Now for the access groups.  All of our access groups should have users:
# parameters so there are no access groups that match connections without
# an identity (such as are generated by the "abusers" entry above).
# First, the default case of local users, who get to read and post to
# everything.

#access "local" {
#    users: "<local>@example.com"
#    newsgroups: "*"
#}

# Now, the read-only folks, who only get to read everything.

#access "read-only" {
#    users: "<read>@example.com"
#    read: "*"
#}

# Finally, the events-only people who get to read and post but only to a
# specific hierarchy.

#access "events-only" {
#    users: "<events-only>@example.org"
#    newsgroups: "example.events.*"
#}