(ITS#7347) Exclusive bit masks for: ACL_WADD, ACL_WDEL, and ACL_WRITE

[daniel@pluta.biz]

Full_Name: Daniel Pluta
Version: MASTER
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (2001:470:9feb:ff03:e455:e36f:5b06:b2f1)


The "Enhancement for dnattr=... ACL" we've described within the LDAPcon2011
paper (http://www.daasi.de/ldapcon2011/downloads/plutahommelweinert-paper.pdf,
Chapter VI, Section G., pdf page 7, left column bottom) seems to be still very
useful in our opinion.

We (Peter an me) have discussed the idea behind this enhancement together with
Howard during dinner the day before the LDAPCon2011 officially started. We
described the enhancement as some kind of
"dnattr-based-administrator-less-2-way-handshake-entry-responsibility(-owner)-transition".

Until today ITS#6900 contains a prototypical patch (very dirty hack), to
demonstrate the described enhancement's mode of operation.

The good news:
Probably this hack isn't needed anymore in the future and thus ITS#6900 could be
closed, but just in case ...

The bad news:
... another (hopefully) less intrusive and generally useful patch, that seems to
be implementable without introducing new keywords can be realized instead:

In http://www.openldap.org/lists/openldap-technical/201208/msg00040.html Kurt
explained that the acl privilege levels "a" and "z" share one bit with the "w"
privilege's bit set. Thus currently neither "a" nor "z" can be independently
substracted from "w" in the way either "z" or "a" remains in the privilege set.
Subtracting "a" or "z" results in removing the complete "w" privilege (including
"a" and "z").

In case the bit masks of the privileges "a", "z", and "w" can be separated
(introducing exclusive masks for ACL_WADD, ACL_WDEL and ACL_WRITE), the
following acl set offers the above described mode of operation (out-of-the-box
without the need to apply the hack submitted with ITS#6900):

{0}to dn.base="ou=groups,o=iacm" attrs=children  by users write  by * none
{1}to dn.one="ou=groups,o=iacm" attrs=owner  by dnattr=owner =dxcsraz continue 
by dnattr=modifiersName -z  by * none
{2}to dn.one="ou=groups,o=iacm" attrs=entry,@groupOfNames by dnattr=owner write 
by * none

I've not been able to test this acls yet (due to no available hack/patch). At
least in theory it should represent the mentioned enhancement's mode of
operation:
The owner attribute can be modified (add and delete) by any owner, but no owner
can remove himself from the owner attribute to either repudiate his personal
responsibility for an entry or to produce a dangling entry (an administrator
needs to clean up), in case it's the last owner.

Herewith, the request for a more detailed description of a usecase where
substractive privileges are of general use should be answered. Additionally I
also thought about the statement, that "good ACLs" are either static or
additive: I have not been able to find a static or additive ACL solution to
implement the above described functionality in a similar elegant way (e.g.
without administratively maintained group patterns).

Alternative 1: (elegant static/additive ACL)
There possibly exists a solution to express the above described mode of
operation already nowadays by using static and additive acls only, if so, I
appreciate any advice.

Alternative 2: (coding the bitmask-separation)
I have no clue how(h)ard ;-) it is to implement (especially test) a successfull
separation of these bit masks. It was mentioned that the incremental processing
of privileges has been added later and the underlying design could be
suboptimal. Currently I don't know which pitfalls to be aware of (especially in
and around acl.c). Nevertheless and depending on the answer to alternative 1,
I'm interessted to give it a try, thus any thoughts and hints are very welcome,
too.

Thanks a lot!