[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