[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: Overlays : Cache - Entry - AttributeDescription
A correction to my last message:
> If you want to free the entry yourself, instead you can do
>
> rs_replace_entry(entry_dup(rs->sr_entry));
e = rs->sr_entry;
.... send the entry, or whatever...
entry_free(e); /* instead of entry_free(rs->sr_entry); */
I don't quite remember, but I think when rs->sr_flags does not assert
ownership of the entry, some other module may change the sr_entry
pointer. So entry_free(rs->sr_entry) could free the wrong entry.
Johan Jakus writes:
> I'd like to make the attributes I merged in the entry
> "read-only". Because the clients will receive an attribute from the
> parents of an object, and I don't want them to to be able to save that
> attribute in the object,when for example they change other attributes
> values and click on the modify button in a program. Would You have any
> idea on how to make that possible?
Don't know, but try access controls to prevent user modifications,
then bypass that for the mods done by the overlay with
<Modifications>.sml_flags |= SLAP_MOD_INTERNAL;
Maybe something like
objectclass ( <oid> NAME 'jakusAddedAttrs' AUXILIARY
MAY ( managed_attr1 $ managed_attr2 $ ... ) )
...
access to filter=(objectclass=jakusAddedAttrs) attrs=@jakusAddedAttrs
by * read
The alternative would be to intercept update operations and return
(prohibited mod ? LDAP_UNWILLING_TO_PERFORM : SLAP_CB_CONTINUE).
--
Hallvard