harry.jede@arcor.de wrote:
> Michael Ströder wrote:
>> 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'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.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature