Hi guys,

I have a minimally working CVS HEAD version now (which I commit on tuesday). There are two big pending issues - etc/rbac/mcds/*.xml and multi-role/multi-person approval. I send a second mail for approval.

I think all these xml files makes not much sense. We do a lot of I/O only to understand what do the capabilites of our own loaded commands are. Additionally every file is usually implemented once and never used again. We only noticed them if we forget to create or install one.

Additonally they create a problem in the access control. We have always an owner_method even if there is no owner (e.g. genDB).

I recommend to throw away this stuff an replace it by a simpler solution. The commands are always loaded. So why do we do not using them? I have the following idea:

Example: OpenCA::Server::Command::insert_csr.pm

$AC::operation = "csr insertion";
$AC::owner = "REQUEST";

The operation is the same like the today's XML tag operation. Owner is a simplification with a more powerful logic. If the value is an OBJECT CLASS (like REQUEST) then we use the parameter KEY to load the object from the database and take the role from the loaded object (e.g. approve_csr). If the value is ROLE then we use the parameter role to read the role from it (e.g. insert_csr). If the value is empty then there is no role.

I think this would simplify a lot of stuff in the access control because XML is nice but perl modules are better especially if they are already present and loaded. The change would be really easy and make the code much more robust and easier to maintain (two variables vs. a XML file).

Any comments?

Michael
--
_______________________________________________________________

Michael Bell                    Humboldt-Universitaet zu Berlin

Tel.: +49 (0)30-2093 2482       ZE Computer- und Medienservice
Fax:  +49 (0)30-2093 2704       Unter den Linden 6
[EMAIL PROTECTED]   D-10099 Berlin
_______________________________________________________________

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature



Reply via email to