readers.conf -- is this possible

[Russ Allbery]

Todd Olson <tco2 at cornell.edu> writes:

>>> 2) make a new key in the existing access block, that 
>>>    adds to, rather than replaces the wildmats
>>>     (will this work in the current readers.conf ??)

>> Of those, we're going to get #3 eventually, but #3 is the most
>> complicated for the local administrator since they're generally going
>> to have to write some code to use it.  Of the rest, I like the idea of
>> #2, and yes, I think it should work even with the current parsing
>> infrastructure.  It should be possible to make it work in the new
>> parsing infrastructure as well.

> Hum ... but I'm worried about #2 working.
> Suppose I have two access blocks for the a particular ID
> Does the current nnrpd 
>     a) evaluate the first access block and then evaluate the
>        second access block, having it overwrite the first access
>        block's settings?
> or
>     b) search for the last ID match (in this case the second access block)
>        and evaluate just that?

Currently, it does the latter, so yes, in order for #2 to work, you'd have
to rearchitecture the way in which access groups are handled some.  I
think that's doable, but you're right, it would require a good bit of
thought on the best way to do it.

> Any additional pointers you could give on this matter would be much
> appreciated.

PERMgetpermissions in nnrpd/perm.c is the core of this code.

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