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

[Jeffrey M. Vinocur]

On Mon, 27 Jan 2003, Todd Olson wrote:

> 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

*nod*

Not bad, not bad.


> Finally, this approach is a big win over having a auth_perl thing
> that returns the access list [ ...ease of mainenance... ]

Agreed.


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

In 2.4, it would be doable but require some pounding on the parser which
would be a bit of a waste since the whole parser is going to get ripped
out and replaced with Russ's generic config parser.  However, adding that
at the time the parser is replaced might be doable.


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

I think we'd prohibit everything except users:, key:, read:, and post: -- 
can you think of any good reasons to support other parameters?


Actually, wait.  Maybe we don't need to add another block type at all.  
What about just changing the semantics of access blocks by making 
append-all-matching-access-blocks a standard thing, modified either by a 
"break: true/false" keyword or a "fallthru: true/false" keyword (depending 
on what seems most intuitive to people, and backwards-compatibility 
issues) to allow the admin to stop the appending process as desired.

Thoughts on that instead?


-- 
Jeffrey M. Vinocur
jeff at litech.org