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

[Jeffrey M. Vinocur]

On Thu, 30 Jan 2003, Russ Allbery wrote:

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

Hmm, that's true.


> how patterns like "foo.*, at foo.bar.*" append to "!*bar*,*foo*".

I've never liked the semantics of ME in newsfeeds either.  But I think 
straight concatenation would work (especially since if you want to append 
something but the original has a "trailing exclusion" you can just stick 
that exclusion in another block to be append after all the intermediate 
stuff).

If that makes any sense.

But in general, I think something like this would be helpful.


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

Ah, but this is fundamentally access control, and not authorization.  I 
definitely don't want to duplicate my (hypothetical) "take the union of 
all these access lists" code into every authenticator and resolver I use!

The only way to do this properly at present is with perl_access, or to 
give up on readers.conf entirely and reimplement the "try multiple 
methods" functionality from scratch.

I think.


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

Just making the current behavior the default would get that, though.  As 
long as the default is "break: true" (or conversly "fallthru: false"), 
existing files will be fine exactly as is.


-- 
Jeffrey M. Vinocur
jeff at litech.org