Access and Authentication

Access and Authentication

The AccessList decides which clients may connect, which groups they see, read and post to, and whether they log in. Nothing is allowed by default, not even localhost: a client without a matching entry gets 502 You have no permission to talk. Goodbye.

AccessList entries

AccessList {
  Client 192.0.2.0/24 {
    allow read post
    List *
    Read *
    PostTo *
    Authentication none
  }
  Client 2001:db8::/32 {
    allow read
    List *
    Read *
    PostTo !*
    Authentication none
  }
  Default {
    allow none
  }
}

• The first matching entry is used, so put Default last. Without a Default entry the file doesn't load.
• Client takes:
  • an IPv4 or IPv6 address with a prefix length (192.0.2.0/24, 2001:db8::/32) or a netmask (192.168.0.0/255.255.0.0). An empty prefix length (192.0.2.0/), one above 32 (IPv4) or 128 (IPv6), and a netmask with gaps (255.0.255.0) are configuration errors;
  • a plain address, which means exactly that host (Client 10.1.2.3);
  • a host name (exact match, news.example.org) or a domain suffix starting with a dot (.example.org), matched against the client's host name;
  • stdin: the client of an inetd session (newscache -i).
• IPv4 clients of the dual-stack listener (ListenTo DEFAULT) are matched by their plain IPv4 address.

Check what NewsCache made of the file with newscache -p, and what a connected client gets with xdebug dump authorization (needs debug).

Rights

Setting	Meaning
allow read post debug authentication none	read: reading commands; post: POST; debug: the XDEBUG command (it shows the configuration, without upstream passwords); authentication: lets a client whose entry allows nothing else stay connected so that it can log in (it gives no right by itself and doesn't make the login required); none: nothing. An entry that allows nothing gets 502 at connect.
List groups	Groups shown by LIST, LIST NEWSGROUPS, NEWGROUPS and the like; a wildmat in the command only narrows this list.
Read groups	Groups the client may select and read.
PostTo groups	Groups the client may post to.

Group lists are comma-separated; a name may end in *, and ! excludes: *,!alt.binaries.* is everything except alt.binaries. The most specific match wins.

Read is enforced everywhere: GROUP, LISTGROUP, and the message-ID forms of ARTICLE, HEAD, BODY, STAT, HDR, XHDR and XPAT (an article fetched by message-ID must be in at least one group the client may read, judged by its Newsgroups header). A post is refused if any of its groups is not in PostTo. The names in the Newsgroups header are separated by commas, with optional blanks or tabs around them; a name with white space in it is refused with 441 invalid Newsgroups header.

Logins

Authentication selects how a client logs in (AUTHINFO USER / AUTHINFO PASS) and what a login adds:

Value	Meaning
none	No login.
file:/path	Users from a password file (below).
unix[:list:read:postto:allow]	Local accounts (getpwnam/getspnam); see the limits below. Without fields, the login is required.
pam[:list:read:postto:allow]	PAM (build with --with-pam); service newscache, or the one set with PAMServicename. PAM gets the client's address as PAM_RHOST when available, so host-based rules (pam_access, pam_succeed_if rhost) apply; inetd -i or an unavailable peer address supplies no remote host.
pam+file:/path	Password checked by PAM, extra rights from a file (below).

PAMServicename must name an installed PAM service. A missing service is warned about at startup and reload; depending on PAM configuration, it may fall back to the system's other policy. Configuration values are not quoted: PAMServicename "" names two literal quote characters, not an empty value. See newscache.conf(5).

A login adds rights to those of the entry.

Only Authentication unix without fields makes the login required: until then every command but CAPABILITIES, MODE READER, AUTHINFO, HELP and QUIT gets 480, whatever the entry allows. With file:, pam (also without fields), pam+file and unix with fields the login is optional: the client has the rights of its entry from the start, and a login adds those of the user. That gives two patterns:

Only users who log in: the entry allows only the login, and the user file gives the rights.

  Default {
    allow authentication
    List !*
    Read !*
    PostTo !*
    Authentication file:/etc/newscache.users
  }

The login is optional here too, but the entry gives no rights, so nobody reads or posts without one: until the login, the commands that need a right get 480 Authentication required. Commands that need none, such as DATE, HELP and CAPABILITIES, work. The greeting is 201 (posting prohibited), and CAPABILITIES lists AUTHINFO USER but not READER, HDR, OVER, LIST or POST.

Login optional: allow read post together with Authentication file:... lets everybody read and post without logging in; a login only adds rights (for example "everyone on the LAN may read, users who log in may post too"). Don't use this if you want to keep strangers out.

The user file

One user per line:

user:hash:list:read:postto:allow

• Only user:hash is required. Missing fields at the end add nothing, like empty ones: alice:$6$... checks the login only, and the client keeps the rights of its entry.
• list, read, postto are group lists that are added to the entry's List, Read and PostTo.
• allow adds rights (read,post,debug). !read, !post and !debug remove that one right.
• Password hashes are checked with the system's crypt(3); supported algorithms vary by platform. For example, openssl passwd -6 generates SHA-512 crypt where the system supports it. The default Apache htpasswd APR1 ($apr1$) hashes are not supported by the system crypt(3) implementations used with NewsCache. The default build also recognizes legacy unsalted base64 MD5 hashes; these are weak and should not be used for new passwords. With --without-md5auto, crypt hashes do not work. Plain-text passwords require --enable-plainpass; a locked field (*, !...) or an empty one never matches. A stored hash that cannot be checked refuses the login and logs an error. See newscache.conf(5).
• Lines may be of any length.

Example:

alice:$6$xyz...:*:*:*:read,post
bob:$1$abc...:*:de.*:de.*:read

NewsCache reads the file at login, after it has switched to its Username (news), so that user must be able to read it:

chown root:news /etc/newscache.users
chmod 0640 /etc/newscache.users

pam+file

The file has the fields name:list:read:postto:allow, like the user file but without the password. name is a user, @group (a group the user is a member of) or * (every user):

hugo:at.test:at.test:at.test:post
@mygroup:de.*:de.*:de.*:post
*:us.*:us.*::

After PAM has accepted the password, the rights of every line that applies are added: the line *, the lines of the user's groups, and the user's own line. A user without a line of their own gets the rights of * and of their groups. If no line applies, the login is refused.

unix and PAM: local accounts don't work

NewsCache checks passwords after it has switched to Username, and only root may read /etc/shadow. So:

• Authentication unix can't check local accounts with shadow passwords; the log says "cannot read the shadow password".
• Authentication pam with pam_unix (what password-auth and common-auth use for local accounts) fails the same way: run as news, its helper unix_chkpwd only checks news's own password. NewsCache logs PAM's error with a hint.

Use the user file (file:), or PAM modules that work without root, such as pam_sss (SSSD, LDAP, FreeIPA), pam_ldap or pam_pwdfile. Running NewsCache as root to get around this is not recommended.

Failed logins

After a failed AUTHINFO PASS, NewsCache waits AuthFailureDelay seconds (0 or 1, default 1; larger values from older configs count as 1), the same after each failure, then answers 481. (Up to 1.3.22 the delay was multiplied by the number of failures: 15, 30 and 45 s by default.) After a failed PASS, send AUTHINFO USER again. Malformed auth... commands are logged with their command word only, never with a password. After the third failure it answers 400 ... service discontinued and closes the connection, whatever the LogStyle.

The log names the account of a successful login ("authenticated as ", level notice). Passwords are not logged, and the client's password is cleared from memory right after the check.

Reply codes

These follow RFC 3977 and RFC 4643 (AUTHINFO).

Situation	Reply
No matching entry, or allow none	502 You have no permission to talk at connect, then the connection is closed
Greeting and MODE READER	200 if the client may post at that moment; otherwise 201 ... posting prohibited (read-only entries, entries that allow only the login, and before a login that is required or would add the post right)
A command the entry doesn't allow, and a login could allow it	480 Authentication required
A group or article the client may not read, and a login could help	480
The same, but the client is logged in or its entry has no Authentication	502 access denied
A command the entry doesn't allow, and no login could allow it (Authentication none, or after the login)	502 access denied; POST without the post right gets 440 posting not permitted (RFC 3977). An unknown command gets 500 What?

| POST: a group not in PostTo | 441 after the article (the only failure reply RFC 3977 allows there); while a login could add the group, the text says "authentication required" | | AUTHINFO USER name | 381 | | AUTHINFO PASS with the right password | 281 | | A failed login: wrong password, unknown user, a stored hash that can't be checked, a refusal by PAM, a name or password over 511 characters | 481 | | AUTHINFO PASS without AUTHINFO USER before it, also after a failed PASS or a USER that was too long (send AUTHINFO USER again) | 482 | | AUTHINFO after a successful login, or where the entry has Authentication none | 502 | | AUTHINFO with wrong syntax or an unknown subcommand | 501 | | AUTHINFO USER/PASS on a plain connection where the entry has AuthRequiresTLS yes (from 1.3.23) | 483 |

Newsreaders offer a login only after a 480, so entries that allow a login use 480 until the client has logged in. MODE READER and CAPABILITIES are answered before the login too.

Up to 1.3.22 a failed login got 502, the greeting always said 200, MODE READER answered 200 or, before the login, 480, and POST could answer 480, 440 or 449 after the article. A script that looks for 502 after a failed login must look for 481 now.

CAPABILITIES shows what the client may do at that moment: READER, HDR, OVER and LIST ... only with the read right and not before a required login, POST only with the post right, AUTHINFO USER only before a login (and only where the entry has an Authentication). With AuthRequiresTLS yes, a plain connection sees AUTHINFO without USER.

AuthRequiresTLS yes in an entry (from 1.3.23) lets its clients log in only over TLS; see TLS for Clients.

See also

• newscache.conf(5), sections "AccessSpec" and the examples
• doc/newscache-pam.txt
• FEDORA.md, "Letting clients in"