[Bug 1690] AllowUsers and DenyGroups directives are not parsed in the order specified

[bugzilla-daemon at bugzilla.mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=1690

junk at buler.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |junk at buler.net

--- Comment #2 from junk at buler.net 2011-08-25 14:40:39 EST ---
I have to agree that this is a bug. The logical order of DenyUsers,
AllowUsers, DenyGroups, AllowGroups that is noted in the documentation
makes sense. The implementation does not.

First off, DenyUsers works properly and can be ignored for this
discussion.

However, ask this: if an administrator SPECIFICALLY grants access to a
user by listing their ID in AllowUsers, why should they be subject to
further restrictions?

In any case, here are the Allow/Deny tables for the existing and
patched systems. The cases that would be changed are noted with an "*"

AllowUsers    DenyGroups    AllowGroups    Result
F            F            F            Deny
F            F            T             Allow
F            T            F             Deny
F            T            T            Deny
T            F            F            Deny
T            F            T            Allow
T            T            F            Deny
T            T            T            Deny

New            
AllowUsers    DenyGroups    AllowGroups    Result
F            F            F            Deny
F            F            T            Allow
F            T            F            Deny
F            T            T             Deny
T            F            F            *Allow* Case 1
T            F            T             Allow
T            T            F            *Allow* Case 2
T            T            T            *Allow* Case 3

Take each of the three cases:

1. User is AllowUser but not in DenyGroups or AllowGroups. This adds
valuable functionality. Say you have users A and B in group 1 and users
C, D, and E in group 2. You want to allow users A, C, D, E. If you
define AllowUsers A and AllowGroups 2, user A will be rejected because
they are not part of group 2. The only alternative is to AllowUsers A,
C, D, E and not define AllowGroups. That is illogical.

2,3. The change in result from Deny to Allow where a user is an
AllowedUser yet is a member of a DenyGroup is not as controversial a
change as it may appear. Currently, the system is totally ignoring the
AllowUser configuration when the user is a member of a DenyGroup. So
the AllowUser configuration shouldn't even be in the configuration. 
Assuming most admins are smart enough to understand that, and don't
have AllowedUsers that are also members of DenyGroups there should't be
any significant repercussions.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.