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:
- 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 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.