Re: Concerns with OLC (cn=config) for editing schema, ACLs, and deleting entries

[harry.jede@arcor.de]

Michael Ströder wrote:
> harry.jede@arcor.de wrote:
> > Nick Milas wrote:
> >> This actually is causing a serious problem (I would even call it a
> >> "*hell situation*"), because we can no more export/view our ACLs
> >> as ldif in a legible form. Moreover, we cannot edit this exported
> >> ldif and import it back to cover several editing needs.
> > 
> > I am pretty sure, that after you have added the '\n' you have
> > broken the ldiff format.
> 
> Harry, as said in this discussion thread:
> 1. LDAP syntax DirectoryString may contain CR and LF.
> 2. RFC 2849 defines SAFE-CHAR which does not contain CR and LF
> 
> => a DirectoryString attribute value containing CR or LF has to be
> base64-encoded when generating LDIF.
> 
> There's nothing wrong with that.
You describe the internal way how a LF in a DirectoryString is handled.
I believe that this is all right and that my previous statement
"broken ldif" is not really true. But it touches Nicks problem he
called "hell situation".

> > You may try '\n '.
> 
> Adding \n is a work-around when working with some shell commands.
> This is not relevant here.
Indeed it is.
If one adds a LF to a DirectoryString like olcAccess via a GUI-Tool one
gets beautified olcAccess fields in this GUI-Tool. Fine?

Now, one wishes to export/view/modify the olcAccess lines and get base64
encoded strings, i.e.
olcAccess:: ezB9dG8gYXR0cnM9dXNlclBhc3N3b3JkLHNoYWRvd0xhc3RDaGFuZ2UKIGJ5IHNlbG
 Ygd3JpdGUgYnkgYW5vbnltb3VzIGF1dGgKIGJ5IGRuPSJjbj1hZG1pbixkYz1rcm9ucHJpbnosZGM
 9eHgiIHdyaXRlCiBieSAqIG5vbmU=

OK, no problem. We decode it, after we removed '\n ':
# echo 
'ezB9dG8gYXR0cnM9dXNlclBhc3N3b3JkLHNoYWRvd0xhc3RDaGFuZ2UKIGJ5IHNlbGYgd3JpdGUgYnkgYW5vbnltb3VzIGF1dGgKIGJ5IGRuPSJjbj1hZG1pbixkYz1rcm9ucHJpbnosZGM9eHgiIHdyaXRlCiBieSAqIG5vbmU='|
base64 -d
{0}to attrs=userPassword,shadowLastChange
 by self write by anonymous auth
 by dn="cn=admin,dc=kronprinz,dc=xx" write
 by * none

So, now we have a situation, where we have produced "INVALID LDIF".
The right format SHOULD look like this:
{0}to attrs=userPassword,shadowLastChange
  by self write by anonymous auth
  by dn="cn=admin,dc=kronprinz,dc=xx" write
  by * none

The difference is that we have two spaces in front of each by clause.
The "first space" is part of the "line continuation".
This can be directly added with ldapadd/modify.

What I called "INVALID LDIF" must be base64-encoded before sending to the
server (not tested). If one miss this step, ACLs will not work as expected.

And all this trouble is only required to beautify a GUI ;-) . I think
that is a wrong approach. GUI-developers should avoid to embed LF in
olcAccess fields, even if it is allowed to do. I think a much better
approach is to reformat olcAccess fields, so that their content could be
easy copied/pasted by users.

Once again, this is readable by humans, may be copied/pasted by humans,
and is still accepted from openldaps ldiff parser:

dn: olcDatabase={1}hdb,cn=config
olcAccess: {0}to
  attrs=userPassword,shadowLastChange
  by self write
  by anonymous auth
  by dn="cn=admin,dc=kronprinz,dc=xx" write
  by * none
olcAccess: {1}to dn.base=""
  by * read



> Ciao, Michael.


-- 

Harry Jede