Re: [AC] Access Control Algorithm

On 2007-04-26 16:53:01 -0700, Jonas Sicking wrote:

> An even better idea occured to me. How about the following syntax:

>   rule    ::= deny | allow | default
>   deny    ::= "deny" (pattern)+
>   allow   ::= "allow" (pattern)+
>   default ::= "default" (pattern)+

> The rules are match first-to-last, if a 'default' rule is hit
> processing of the header is stopped and only the PI rules in the
> document. This allows the same set of rules to be constructed as
> if we had 'exclude' on both deny and allow, but is IMHO easier to
> read and see what matches what.
>
> The name 'default' might not be ideal. 'none' or 'page' are other
> names i could think of.

This proposal opens up all kinds of interesting interactions between
headers, content, and content-negotiation (what if a resource with a
default has XML and non-XML representations?).  I'm not convinced
we'd want to go down that way.

(As a reminder, the earlier proposal from Brad Porter had all kinds
of bells, whistles, and precedence rules, and was found too complex
not just by me. I'm sensing that we're now going full circle toward
the very same proposal again, which I wouldn't support.)

On 2007-05-03 04:24:01 -0700, Jonas Sicking wrote:

> I know, but I propose we change that since I think the current
> algorithm is hard to easily see what results it produces, as you
> described in the initial mail in this thread.

I don't see how that's the case, sorry.

> My propsal was that we have "allow", "deny" and "default" for the
> HTTP header and "allow" and "deny" for the PIs. The logic would
> be exactly the same between them. We could even have "allow",
> "deny" and "default" for the PIs and let the processing be
> exactly the same, the effect would be that for PIs "deny" and
> "default" would have the same effect.

This adds even more complexity to understanding what policy reall
applies.  Can we please try to keep the policy language as simple as
possible, and make sure that additional complexity is only
introduced where it's *really* needed?

On 2007-05-03 14:34:41 +0200, Anne van Kesteren wrote:

> With the algorithm you are proposing now that is true as well, fwiw. Because 
> even though it can say deny= in the processing instruction that isn't 
> actually true for same-origin requests for instance. And for non same-origin 
> requests the default is deny. Therefore the allow / exclude mechanism makes 
> sense. It also cateters for:
>
>   allow <*.example.org> exclude <*.public.example.org>
>   allow <webmaster.public.example.org>
>
> I'm not really convinced we should throw that away in favor of deny=.

+1

On 2007-05-07 17:31:17 +0200, Anne van Kesteren wrote:

> Yes, my proposal was to allow "deny <rules> exclude <rules>" in
> addition on HTTP headers.

Ugh.  That once again introduces an order dependency when evaluating
the header, and makes things unnecessarily more fragile.

(Also, you mentioned the effect on same-origin requests yourself,
which might be rather unintuitive...)

On 2007-05-07 10:18:30 -0700, Jonas Sicking wrote:

> I have been thinking about this over the past few days and I actually think 
> I agree with you. While it might be confusing that
>
> allow <*.bar.com> exclude <foo.bar.com>, allow <*.bar.com>
>
> allows foo.bar.com. I think it's even more confusing that
>
> allow <*.bar.com>, deny <foo.bar.com>
>
> does. So I think we should have both 'allow' and 'deny', both
> with 'exclude'. Ordering is not important, but deny rules are
> processed first.

I get back to my earlier argument: This suggests to a policy author
that they can further restrict existing policies.  Have fun with the
bugreports.

Regards,
-- 
Thomas Roessler, W3C  <tlr@w3.org>

Received on Monday, 21 May 2007 10:58:11 UTC