[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Test operations
Morteza Ansari wrote:
Howard Chu wrote:
Morteza Ansari wrote:
I definitely second this, SunDS also supports this control (I am not
sure if the two implementations are 100% compatible though).
Converging on this would make app's developers job easier.
Interesting, considering that this draft hasn't progressed very far
and has no OIDs assigned. How exactly do you expect anyone to write a
compatible implementation? And of course "It is inappropriate to use
Internet-Drafts as reference material or to cite them other than as
"work in progress.""
Having a "standard" would be great, but "similar" implementations is
better than nothing! If the implementation of SunDS and/or Netscape
are interoperable and we have one that is closely related to that it
is better than nothing. I know, I have low expectations!
I guess you have a point; if they really are interoperable then it's
probably a win. But a loose reading of your first sentence sounds like
heading down a path for which Microsoft is so well known...
The old draft mentioned support for X.500 access controls, but the
latest draft (rev 06, 14 July 2000) doesn't mention it any more. All
of which may be academic since the LDAPext working group shut down
and this draft expired in January 2001.
This draft
http://www.ietf.org/internet-drafts/draft-legg-ldap-acm-bac-03.txt
is at least current, and the X.500 models it describes have already
been widely implemented by X.500 vendors. In this respect, it doesn't
have the shortcomings of the LDAPext model (which among other things
doesn't allow for value-specific rights).
I don't know what Steven's plans are regarding moving this forward at
IETF, but I have a feeling it probably won't get adopted by most
vendors. It is unfortunately, but I think collectively we as a
community failed to agree on ACL and replication and now everyone has
their own implementations with little hope of ever getting to a
standard solution.
Speaking of which, a brief digression to an ACL rights model I toyed
with a couple years ago, borrowing a bit from DG AOS...
P - Permit - allows changing the ACLs on an object
A - Append - allows creating new objects
R- Read
M - Modify
E - Erase
S - Search
N - Name - allows renaming objects
(PARMESN, a robust and flavorful access control model. Think it's too
cheesy?) (OK, ok, I apologize for making anyone read that...)
Before going off and implementing an expired draft, it would be nice
to understand why the model never made it beyond draft status. Surely
it does not reflect well on the described model for it to have been
abandoned by the authors. Nor would it reflect well on us to claim
support for what can only be considered an incomplete specification.
From what I recall it was a combination of too much discussions and
vendors needing a solution for their products which resulted in many
un-interoperable(?) solutions.
By no means I am suggesting implementing getEffectiveRights control
solves all ACL problems. However, if we are going to implement
soemthing like that, we might as well implement the same one that
other vendors have implemented (assuming there are no major issues
with it).
Right. As to that, someone must have a spec for what Netscape and/or Sun
actually implemented. That would be a good starting point, but we
already know that OpenLDAP's ACL mechanism has more access control
factors than can be expressed in the LDAPext drafts, so unless we extend
the spec we can't offer accurate info to a client. And if we do extend
it, then we can't guarantee interoperability any more. So we're left
with the choice of being compatible but giving out wrong information, or
being accurate but not being compatible. Personally I would choose not
to sacrifice accuracy/correctness.
--
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support