harry.jede@arcor.de wrote:
Michael Ströder wrote:
Harry, as said in this discussion thread:
- LDAP syntax DirectoryString may contain CR and LF.
- 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'm not sure what you consider "internal". The LDIF exported is the interface format. You have to deal with it in some way. You either don't use CR-LF to format your ACLs to have ediable LDIF or you use LF to format your ACLs. That's what was discussed in this thread before.
Maybe what's needed is an editor for LDIF records which handles all this in case LDAP access is not possible anymore. Much work for just some emergency cases.
Please note that directly editing LDIF of back-config was strongly discouraged by the OpenLDAP developers on this list several times. I'd suggest you should re-read the whole thread in the mailing list archive before your next follow-up.
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 ':
As said: Better use a decent LDIF parser.
What I called "INVALID LDIF" must be base64-encoded before sending to the server (not tested).
What are you talking about? The on-wire-format for LDAP does not have to be base64-encoded. Please clearly distinguish LDIF from LDAP string format.
If one miss this step, ACLs will not work as expected.
Why don't you simply test it and see what's the result?
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.
You're completely missing the point: The goal was to make the ACLs more readable for the admin. The GUI just makes it possible for the admin to add the LFs and display the ACL as multiple lines. And now this has the effect that the attributes values in LDIF are base64-encoded. The admin decides whether to add LFs or not.
I think a much better approach is to reformat olcAccess fields, so that their content could be easy copied/pasted by users.
How to reformat them? That's a matter of personal taste. You would have to parse the ACL format.
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
Please add it via LDAP and display it in a LDAP client. It will be a single line which was considered to be less readable.
Ciao, Michael.