readers.conf question

Aidan Cully aidan at panix.com
Sat Mar 3 02:22:57 UTC 2001


On Thu, Mar 01, 2001 at 06:29:03PM, Bettina Fink said:
> Hi,
> 
> after finally getting readers.conf doing what I want, there's
> a question left: I want access from all hosts, if they authen-
> ticate, they can read and post, if not, they can only read
> and have no access to several groups.
> 
> I've first tried:
> 
> auth "all" {
> 	hosts: *
> 	auth: "ckpasswd -f /usr/local/news/etc/newsusers"
> }
> 
> access "fail" {
> 	read: "*,!some.groups"
> }
> 
> access "full" {
> 	users: *
> 	newsgroups: *
> }
> 
> As described in the man page (it's nearly the same setup as
> the example in the man page, the only difference is that I
> used "read" instead of "newsgroups"):
> 
> No res: key and no default: key, so all connects first get an
> empty identity. An empty identity can't match a users: parameter,
> so they fall into the "fail" access group.
> 
> But that setup didn't worked. nnrpd insists on "480". I expected
> that nnrpd gives "no posting" (read: "*,!some.groups") to all
> connects that don't authenticate. But all it says was "480"
> (auth required).
> 
> So I've played around and changed some things and finally got it
> working the way I want:
> 
> auth "external" {
>         hosts: *
>         auth: "ckpasswd -f /usr/local/news/etc/newsusers"
>         default: "<fail>"
> }
> 
> access "full" {
>         users: *
>         newsgroups: *
> }
> 
> access "fail" {
>         users: "<fail>"
>         read: "*,!some.groups"
> }
> 
> It's nearly the same, I just added a default identity ("<fail>")
> and changed the order of the two access groups, because now "users:
> "<fail>"" is more specific and must be placed after the "users: *"
> access group (last match rule).
> 
> So far so nice (except for my headache ;-), but I don't understand
> why the first setup didn't worked.

Tell me what happens when you reverse the order of your access ""
blocks...  I.e., instead of
> access "fail" {
> 	read: "*,!some.groups"
> }
> 
> access "full" {
> 	users: *
> 	newsgroups: *
> }

do

> access "full" {
> 	users: *
> 	newsgroups: *
> }
> 
> access "fail" {
> 	read: "*,!some.groups"
> }
The last access block matching the criteria applies...  I think what's
going on is that there's (probably) a hack in place that allows an access
block with a users: criteria to match the non-user, in order that the
server would return an Authentication Required response if the remote end
had the possibility of authenticating.

Actually, if that is what's going on, I'm not sure that the re-ordering
would solve your problem anyway, since authenticated users would probably
also match the second access group...  I dislike <FAIL>-type default
users in principle, since you could (theoretically) have a user named
<FAIL> on your system...  Perhaps what's needed is a 'no-user' type
keyword in the access block?

--aidan
-- 
Aidan Cully       "I saw Judas carryin' the body/ Of John Wilkes Booth..
Not Panix Staff    Down there by the train..."
aidan at panix.com         -Johnny Cash


More information about the inn-workers mailing list