readers.conf proposal: (was Re: incoming.conf length limits)

[Todd Olson]

Hi
This note proposes a new block type for readers.conf
It is prompted by the following very useful exchange.
My question is, how much work would it take to implement this?


At 15:38 -0800 2003/01/19, Russ Allbery wrote:
>What's missing is this part:
>
>Todd Olson <tco2 at cornell.edu> writes:
>
>>     d) when authentication occurs the id is checked
>>        and certain id's are given access to additional groups
>>        that are not normally accessible  (this feature is used
>>        but not as widely as originally intended).  This is done
>>        by checking against the 'permit server' (CUSSP protocol).
>
>There are two ways that you could add this.  One would be to use the Perl
>authenticators instead of the above and use a Perl interface to CUSSP (or
>Python, if you want).  They can do the same logic as above, but you'd have
>to write a bit of Perl code to do that.  That may actually be an easier
>approach for you, since you have some interesting edge cases that you want
>to deal with.  With the Perl or Python authentication hooks, you mostly
>wouldn't use readers.conf and instead just handle this logic in Perl or
>Python.
>
>The other way to add this would be to hack nnrpd/perm.c to insert a call
>to CUSSP after the readers.conf authentication finishes and replace the
>newsgroup lists returned there with the results of CUSSP if relevant.  I
>think this would be a fairly small patch; it's just a matter of finding
>the right spot in nnrpd/perm.c.
>


PROPOSED for readers.conf:

   access_additions {
        users:  <some pattern>
        read:   cornell.private.*
        post:   cornell.private
   }

This block would be essentially identical to an access block in all
respects except it would be processed AFTER all auth and access processing.
Users that matched a block would get the indicated groups APPENDED
to their access patterns.  (if the user in question had not matched
an access block, then no access_additions would be processed)


MOTIVATION:
Largely driven by combinatoric explosion

For example, suppose there are five(5) certificates that any user could
have, and each certificate entitles the user to access a particular group.
Then there are 2^5 -> 32  different combinations of groups possible.

With the current readers.conf if I have a custom external auth that
returned something like
   user at cornell.edu/|cert1|cert2|...|certN|
where certi is present if that user has that cert

Then I could sort of get what I want with the following:

auth cornell-custom {
    hosts:  *.cornell.edu
    auth:   auth_cornell
    default:  <FAIL>
    default-domain:  cornell.invalid
}

access {
    users:  *@cornell.edu/|cert1|
    newsgroups:  *,!cu-restricted.*,cu-restricted.g1
}

access {
    users:  *@cornell.edu/|cert1|cert2|
    newsgroups:  *,!cu-restricted.*,cu-restricted.g1,cu-restricted.g2
}

access {
    users:  *@cornell.edu/|cert2|
    newsgroups:  *,!cu-restricted.*,cu-restricted.g2
}

... etc ... for all 32 permutations  (or 2^<number of certs>)
            (ie a big hairy combinatoric mess)
            (I'm assuming order of certs is preserved in my custom auth script)



HOWEVER with the proposal I would be able to say


auth cornell-custom {
    hosts:  *.cornell.edu
    auth:   auth_cornell
    default:  <FAIL>
    default-domain:  cornell.invalid
}

access {
    users:  *@cornell.edu/*
    newsgroups:  *,!cu-restricted.*
}

access _additions {
    users:  *@cornell.edu/*|cert1|*
    newsgroups:  cu-restricted.g1
}

access_additions {
    users:  *@cornell.edu/*|cert2|*
    newsgroups:  cu-restricted.g2
}

... etc ... for only 5 (ie <number of certs>) access_additions
            (and I would not even have to worry about cert order ....)



Finally, this approach is a big win over having a auth_perl thing
that returns the access list from a support point of view.  Rather
than having to develop some config file for the perl script that I
have to document and maintain locally, and the readers.conf just
having this mysterious call to a perl authenticator, I can have everything
explicitly documented in the readers.conf file, so any successor to my
job will have a clear indication of what is going on.

QUESTION:
how much work would it take to add such a block to readers.conf??

Regards,
Todd Olson
Cornell University


PS ... hum I guess there would be details, like if access_additions
       had a 'nnrpdauthsender: true' would that turn is on globally,
       or only for the added groups.  The easiest would be to turn
       it on globally, and that would meet my needs.