Re: [Codematch-develop] DataTracker and CodeMatch access control

Robert Sparks <> Wed, 26 August 2015 19:00 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C2B891B312C for <>; Wed, 26 Aug 2015 12:00:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ei8wEHV0Ve1D for <>; Wed, 26 Aug 2015 12:00:11 -0700 (PDT)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 581AB1B311F for <>; Wed, 26 Aug 2015 12:00:10 -0700 (PDT)
Received: from unnumerable.local ( []) (authenticated bits=0) by (8.15.2/8.14.9) with ESMTPSA id t7QJ08jW052976 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Wed, 26 Aug 2015 14:00:09 -0500 (CDT) (envelope-from
X-Authentication-Warning: Host [] claimed to be unnumerable.local
Message-ID: <>
Date: Wed, 26 Aug 2015 14:00:03 -0500
From: Robert Sparks <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Lisandro Zambenedetti Granville <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <>
Cc: codematch-develop <>, Henrik Levkowetz <>
Subject: Re: [Codematch-develop] DataTracker and CodeMatch access control
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"Discussion forum for the planning, coordination, and development of CodeMatch\"" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 26 Aug 2015 19:00:14 -0000

On 8/26/15 1:26 PM, Lisandro Zambenedetti Granville wrote:
> Hello Roberts
> Comments inline...
>> You are not necessarily restricted to the Role names that are defined now (like "chair"). We could add Role names like
>> "codematcher" or "codematch_approver" or whatever other name matches the semantic for the permission you're wanting to manage.
> That’s great, so that we can expand the current Roles without changing the data model.
>> You could then have things like Lisandro Granville is codematch_approver in nmrg.
> That is also what we need.
Just to be sure - you're saying that's sufficient, and while you're 
explaining the idea further below, you don't need it right now?
>> Does that address the need? If not, could you walk me though a scenario where it makes it harder than it should?
> What you mention above is the link among users, roles, and groups. There is another link between roles and permissions that seems to be hardcoded in datatracker. When we say
> if has_role(request.user, ["Area Director", "IAB Chair", "Secretariat”]):
> 	// do things the user with "permission X" can do
> it implies that if we want to grant to, e.g., “codematch_approver” the “permission X” above, we should go back to the code and change it to
> if has_role(request.user, ["Area Director", "IAB Chair", “Secretariat”, “codematch_approver"]):...
> We were then considering the possibility of moving the link between roles and permission to the data model and implement has_right (or has_permission) like:
> if has_right(request.user, “permission X”):
> 	// do things the user with "permission X" can do
> If we want “permission X” to be granted to other roles, that would be a matter of including the proper records in the database, instead of changing the code.
> Trying not to go too much into details, the summary is that we want to check if assigning permission to roles is ok to be done in the database, instead of changing the code.
Well, you still have to type has_right(...) in the code, and specify 
something concrete in that has_right that would have to change,
so I don't think we're really talking about avoiding changing code as 
much as we are about _where_ you model the idea of a permission in the 

I think the real essence of what we're talking about is the difference 
in how you would implement
"Give all the WG chairs codematch-approval rights".

With your proposal, you would make a role to permission match to do that 
- one database row change - pretty efficient (*)
With what we have now, you just add a Role of "codematch-approval" to 
any Person that has a wg chair role.
So, I think what you're proposing is an optimization, and it comes with 
some complexity. We can keep talking about it, but I don't
think we're at the point that we need it.

(*) But, it's not really that easy. Right now we have a role of "chair" 
that is applied to all groups. There's no way to speak differently about 
WG chairs and RG chairs by simply saying "chair" - it takes more code. 
We have chairs of Teams, and _could_ have (but don't currently) chairs 
of other SDOs in the database. So, the apparent simplicity of matching a 
permission to a role-name isn't as strong as it first appears.
>   We are of course talking about the CodeMatch code only; we are not talking about the datatracker code at all, although examples were inspired by has_role, which is used in datatracker.
> Lisandro
>> On 8/25/15 1:52 PM, Lisandro Zambenedetti Granville wrote:
>>> Dear All
>>> Last week we had our traditional CodeMatch meeting. One of the questions discussed in the meeting was about role-based access control (RBAC) in CodeMatch. We would like to propose adding an extra table in the current data model to support RBAC. However, because we want to be as aligned with DataTracker style as possible, we are sending this message to start a discussion, specially with Henrik and Robert.
>>> 1) Style of checking users’ permission
>>> We observed the DataTracker code and it seems that in general, permission checking is hardcoded, in the following style (using “Area Director”, “IAB Chair”, and “Secretariat" as examples):
>>> if has_role(request.user, ["Area Director", "IAB Chair", "Secretariat"]):
>>> 	// do something that only area diretor, IAB chair, and secretariat could do, like “Create CodeRequest"
>>> In CodeMatch, we would like to check permissions in the following way:
>>> if has_right(request.user, “Create CodeRequest”):
>>> 	// do something that only authorized people should be able to do, like “Create CodeRequest”
>>> The “has_right” function would check the database to retrieve the users’ roles and, for each role, check if it has permission to “Create CodeRequest”. In this way, permissions are associated to roles, and roles associated to users.
>>> Because permissions and roles in CodeMatch are being defined together with the implementation of the system prototype, the use of “has_right” would allow us to assign permissions to roles just changing the database, instead of changing the CodeMatch code if we use “has_role” instead.
>>> 2) Database
>>> Today, permissions are listed in table auth_permission. Roles are listed in table group_role. We would need a intermediate table linking permissions to roles, i.e., a table linking author_permissions and group_role. That would allow us to say, for example, that a mentor (inside group_role) can add documents to a codeRequest (i.e., a permission inside auth_permission). Adding this intermediate table (let’s call it role_permission for the moment) would not affect today’s database, although it would expand today’s data model.
>>> Do you think doing that is ok?
>>> Best regards,
>>> Lisandro, Wanderson, Matheus
>> _______________________________________________
>> Codematch-develop mailing list