((AllowUsers || AllowGroups) && !(AllowUsers && AllowGroups))

[James Dennis]

> That's not always the case.  It might make sense to allow access to a
> group, then deny access to a particular member user in that group.  It
> probably never makes sense to explicitly allow access to a user, then
> deny access because that user is in a particular group.

What if the user's group is denied for bad bahavior, but you trust a 
particular user in that group? Perhaps we should stop saying what 
probably *might* happen and accomodate accordingly assuming the strange 
cases probably *will* happen, for whatever reason.

> It seems to me that the most explicit option should take precedence
> (AllowUsers in preference to AllowGroups); perhaps something like
> 
>     if user is in denyusers
> 	deny
>     if user is in allowusers
> 	permit
>     if user group is in denygroups
> 	deny
>     if user group is in allowgroups
> 	permit
>     if #allowusers > 0 or #allowgroups > 0
> 	deny
>     permit
> 
> would make sense?

What if we rearrange things and try to think about how people set up 
rules. If I were to setup rules with permissions of ssh access I'd 
probably explicitly state groups and then users and let the user 
specification override groups if they came after groups, and likewise. 
If we do it in sequential order you can probably have more flexibility 
than by doing it by directive.

Such as:

DenyGroup: badpeople
AllowUser: badperson # they're in badpeople, but can have access

DenyGroup: badpeople # This will undo the allowuser above and re-deny 
everyone in badpeople

Does that make sense at all?

-- 
James Dennis
Harvard Law School

"Not everything that counts can be counted,
and not everything that can be counted counts."