Eric Covener wrote:
I tend to prefer something closer to the old name, especially with the
Satisfy containers being optional. IOTW the "sections" here may not
be something explicit the user can look back to.
(Maybe IOW, "in other words"? :-)
They should be: since <Directory> and friends all function as
<SatisfyAll>, everything is always a section of some type. I could
live with SatisfyOnMerge or something similar, but I'd like "Satisfy"
in there somewhere to clarify the relationship with both the legacy
Satisfy and the new <Satisfy*> blocks.
<Directory /foo>
Require group shirt
Require group shoes
</Directory>
More common migration breakage might be using two different authz
providers there.
Yes, and in that case, adding a <SatisfyAny> would be needed.
Or, changing the default, which is simple. I'm inclined to commit
as written, and if it looks like this is a sticking point, change it.
That should be trivial, since SatisfySections Any creates exactly
the same thing (during a per-dir merge), so the code paths are
all tested already.
When do we need the negative satisfy containers? I'm having a hard
time with this one, especially with how negating Require/Reject are
interpreted inside -- it almost seems like the containers should be
dictating the verbs and you should just have some more agnostic
match-type operator with the authz providers.
I suppose the most likely case might be something like:
<Directory /humans_and_friendlies_only>
Require valid-user
<SatisfyNotAll>
Require group alien
<SatisfyAny>
Require group hostile
Require group neutral
Require group noninterventionist
</SatisfyAny>
</SatisfyNotAll>
</Directory>
so "aliens" are OK, unless they're in one or more of a set of
other groups. Presumably you can't just say "Reject group alien"
at the top level because some aliens are OK, nor can you say
"Reject group hostile" at the top level, because some hostiles
are human. Probably makes the most sense with complex LDAP setups
where people belong to lots of overlapping categories.
I think negated sections are pretty clear and have some utility;
at a minimum, providing the ability to negate a single match
(i.e., Reject) but no equivalent negation operator at a higher level
makes for some odd constructions which can be more clearly expressed
with higher-level negation. It's the equivalent of negated
parenthetical constructions in logical expressions, like !(A && B).
As you note, it's a little counter-intuitive to be using Require/Reject
in these locations -- something like Match and NotMatch might make
everything clearer. I'm happy to consider such a thing; I think I'll
get the commit in first and then we can adjust further.
The main reason to keep Require, of course, is backward compatibility.
But we could set that up to work like Match, say, and throw an error
unless it's used in a "naked" context (outside of any <Satisfy*>).
That would be easy, and then for configurations with <Satisfy*> blocks,
one would use Match/NotMatch inside of them.
Chris.
--
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
