readers.conf question

Russ Allbery rra at stanford.edu
Sat Mar 3 07:13:05 UTC 2001


Okay, I took a long look at this and discovered that I just hadn't read
the code well enough the first time.  If there are no matching auth groups
(defined as auth groups that yield a non-NULL user), then the access
groups aren't looked at at all.  It doesn't matter what's in them.

There *is* code in there to handle the case that I thought existed, namely
a user equal to the empty string, but it never really triggers except
under very strange circumstances so far as I can tell.

An access group without a users parameter is basically in all ways
equivalent to an access group with a wildmat of "*".

Bettina Fink <laura at hydrophil.de> writes:

> after finally getting readers.conf doing what I want, there's a question
> left: I want access from all hosts, if they authenticate, 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"
> }

So here's what happens, step by step, when a client connects:

 - All auth groups are scanned and the ones that don't match the client
   IP address are eliminated.

 - Each auth group is scanned from the last to the first, and an attempt
   is made to apply it to the current connection.  This means running res:
   programs, if any, and otherwise applying default:.  The first auth
   group to return a valid user is kept as the active auth group.

 - If no auth groups yield a valid user but some of the auth groups have
   auth: lines (indicating a possibility that the user can authenticate
   and then obtain permissions), there is no valid auth group (which means
   that the access groups are still ignored complete), but the connection
   isn't closed.  Instead, 480 is returned for everything until the user
   authenticates.

 - When the user authenticates, all auth groups with auth: lines are then
   checked from the bottom up and the first one that returns a valid user
   is kept as the default auth group.

 - Regardless of how an auth group is established, as soon as one is, the
   user permissions are granted by scanning the access groups from bottom
   up and finding the first match.

So with your configuration, on initial connection there is no established
user identity, but here is a possibility of later authentication.  So the
client gets no permissions and 480 responses to everything.  As soon as
they authenticate, they then get access "full" since it's the last
matching entry.

> access "fail" {
> 	read: "*,!some.groups"
> }

> access "full" {
> 	users: *
> 	newsgroups: *
> }

The example was definitely wrong.

> 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).

Yup.  This works.  I'd add "*, !<fail>" to access "full" just out of pure
paranoia, but it shouldn't be necessary.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>


More information about the inn-workers mailing list