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

Russ Allbery rra at stanford.edu
Thu Jan 30 23:20:24 UTC 2003


Jeffrey M Vinocur <jeff at litech.org> writes:

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

It makes sense in isolation, but I'm a bit worried that it's going to add
even more to the logical complexity of readers.conf, since now people have
to check if multiple blocks match a given user, and it's not entirely
obvious how patterns like "foo.*, at foo.bar.*" append to "!*bar*,*foo*".

Part of me is inclined to argue that anyone doing the sort of access
control that really needs this level of detail ideally wants to just
construct a custom group pattern for each user entirely inside their
custom-written authentication hook, and if we add that to the external
auth protocol like it already is in the Perl and Python hooks, that will
address the problem.  But that's something of a cop-out, since I can
easily construct artificial examples where that would require writing a
custom authenticator where one isn't necessary now.

Hm.

The advantage of using access_additions or something similar to that as a
separate group is that it doesn't add to the complexity at all for people
who don't use it.

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

    Please send questions to the list rather than mailing me directly.
     <http://www.eyrie.org/~eagle/faqs/questions.html> explains why.


More information about the inn-workers mailing list